Richard Fontana wrote:
But prompted by some questions from mcgrof, I realized that it was
important to make some minor improvements in a successor release to
copyleft-next 0.3.0 in the short term. So I decided to call that version
"0.3.1". The current Drafts/copyleft-next is more like something that is
evolving towards 0.4.0.
Right, I figured that, but the problem is there is no way to follow that as a
branching issue, which is what it is: you forked 0.3.0 to make 0.3.1 (i.e.,
there should be an 0.3.x maintenance branch), but the revision history
doesn't show that. More well below....
(Though as I recently noted this is kind of a nonsensical application
of
the idea of semantic versioning.)
(Note that what I describe above is orthogonal to semantic versioning,
although I'm using it as shorthand above mainly because you've used it in
your versioning.)
> Specifically, I have two parallel incompatible proposals that
I'll pitch
> if you're interested. The first would use the branch/tag structure I
> proposed in the past, and reapply existing history. If you still don't
> like that structure, I also devised in recent years a (complicated)
> method that could keep your basic Drafts/ and Releases/ directory
> structure on master branch and still preserve history properly.
I am interested in such proposals.
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).
BTW, a few other principles of note, which will apply either Proposal:
Merges should be made from pull requests and the like so the initial
contributor/author is identified. Reworked patches shouldn't be done
outside of Git [Fontana, you've done this in the past ;] but rather done in
a personal branch and merged into master so the original contribution plus
the
In other words, squashing commits is good for a software project, but bad
for a license drafting process because it's too easily an accidental (or
purposeful) way to violate HBR and decrease transparency.
My time is limited but my interest is there.
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.
> Right now, the tools are being used but the transparency is not complete.
Well, it's still better than any previous major license drafting
effort I
believe.
Oh, of course, I apologize that my text seemed to hint that there exists a
license drafting project doing better at this. There isn't one. But, that's
actually more incentive for copyleft-next to set the bar high on easy-of-use
in its transparency.
--
-- bkuhn
========================================================================
Become a Conservancy Supporter today:
https://sfconservancy.org/supporter