OK, I've added them. I agree that a branch for every fixup (y in 10.x.y) is overkill.
The plan right now is to build any 10.x.y releases by cherry-picks into the release-10 branch. Eventually HEAD will branch into release-11 for the next major release. On Sat, Dec 8, 2018 at 5:40 PM Taylor R Campbell <campb...@mumble.net> wrote: > > Date: Sat, 8 Dec 2018 17:18:21 -0800 > > From: Chris Hanson <c...@chris-hanson.org> > > > > I'm not using tags, just the separate branch for the release. > > > > The tags don't seem to add much value, and I don't think that use is what > > they're meant for. And it's trivial to figure out what they would be from > > the release changelogs. > > The tag provides name for a snapshot of exactly what the 10.1.3 > release was if I want to reproduce it. It is also helpful for, e.g., > `git describe' to show what changes have happened since the latest > named release. What other purpose are tags for, in any revision > control system? > > > I am considering making a new branch for 10.2.x and so on, derived from > > release-10. I could be convinced that making a branch for every release > > would be reasonable. > > In `a branch for every release', by `release' do you mean, e.g., `the > 10.2.x series', or `the 10.2.1 release'? A single branch for 10.2.x > from which we cut 10.2.0, 10.2.1, 10.2.2, &c., makes sense. Separate > branches for 10.2.0, 10.2.1, 10.2.2, &c., don't seem to make much > sense to me -- presumably those are all fixed to a specific commit, > which is what tags are for. >
_______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
