Simon Wilkinson <[email protected]> writes: > We're not consistent about whether we release from trunk, or release > from a branch. This means that on some occasions the trunk has the tag, > and on others the branch. In a traditional git world, we would have > branched for 1.6.1, committed the changes necessary for 1.6.1 on that > branch, and then merged that branch back into the trunk. This final > merge step has the effect of making the 1.6.1 tag visible from both > branch and trunk, and so would cause both to git describe as > expected.
I'm very dubious about that merge back to trunk. I'm not sure that development model really makes sense. For better or worse, the trunk code and the stable branch code tends to diverge quickly and comprehensively, and we tend to apply separate fixes to trunk and to stable that are not equivalent. Unless we make a reliable, regular habit of commiting -s ours merges in those cases, that merge from stable back to trunk can be a nightmare. I also don't think it's necessary, in that I don't think that the 1.6.1 tag needs to be exposed on the master branch. What I do think is a serious problem is that it's not exposed on the stable branch, and there I don't really agree with the decision to create a separate branch off of stable to do 1.6 release stuff. I sort of see how we got there, but I don't think it's wise. (Of course, I'm not a gatekeeper now, so I can go on about how I would fix things without having to do any of the work....) I think it makes sense to have stable branches, but approaching a stable point release I think the only things that should go into that branch are things that are going into that release, and I would not make any more branches. When the release goes out, it's with that stuff. If one absolutely has to create a sub-branch for some reason (such as a purely platform-specific release), then *that* sub-branch I would merge back into the stable branch to make the tag visible there. On master, I would do something different: tag master with some sort of artifical version at the point that the stable branch splits off. So, for example, when we split off a stable branch for 1.6, we could have tagged master at that point with something else. There are a couple of possible strategies for what "something else" is: * devel/1.7.0 or something similar. This would mean that all packages built from master would be 1.7.0+something versions (or 1.7.1 if one ever incremented it, but I suspect that we just wouldn't). This would mean that the Windows-only release would have been 1.8, and when we split it off we would tag master as devel/1.9.0, and so forth. Basically, reserve the odd numbers for the master branch and as soon as one branches for release, increment (via tag) the versions on master to the next odd number. * devel/1.6.99. This avoids the problem of reserving odd version numbers for packages off of master, while creating a weird artificial version number that might be somewhat confusing. But the same semantics would apply; we would have tagged it devel/1.7.99 when we split off the 1.7 branch and so forth. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
