On 04/30/2016 03:38 PM, Bradley M. Kuhn wrote:
Proposal 0: More traditional branching structure.
This proposal argues that the Releases/ directory is completely useless.
Really, the only non-meta part of the project is *one* document, a single
file, that is the license text. git log on that file should show
*everything*.
Releases are just git tags. Branching is permitted. "Official" branches
exist for new contributions to any "major releases" that might lead to a
maintenance release. Cherry-picking can be used to bring changes back to
main line. The Drafts/ and Releases/ directories go away. Everything is
developed in tree with Git, fully utilizing branches, and tags.
Fontana, if you can get on board with that Proposal as it stands, I'd rather
not bother writing up the details of my other one, because it works but is
complicated, will make hardcore Git people cringe (e.g., I believe Jeff King
called it "manipulating the Git history to lie about what happened with the
files" when I described it to him), and means use of non-upstream scripts
that aren't part of Git proper. I only suggested it because I
(mis-?)remembered the conversation we had about how you liked the Drafts/ and
Releases/ structure).
I don't particulary like the Drafts/ and Releases/ structure. It seems
quite awkward to me, at best. I think that is why I said in the
CONTRIBUTING.md file: "(Any suggestion for a better approach than this
Drafts vs. Releases system would be greatly welcome.)" Until today no
one provided a better approach. :)
I can get on board with Proposal 0.
So, if you like this proposal, I can maybe start tonight poking
around on how
to merge everything in. I would give it an hour and report back how much the
further time commitment will be.
Okay.
Richard