On 17 Sep 2012, at 23:18, Andrew Deason wrote: > > I don't think you can make that say something based on 1.6.1, since the > head of the 1.6.x branch right now is a different branch than 1.6.1. I > mean, if git-version said something like "this is 1.6.1 plus N patches", > that would be incorrect. Since, the head of 1.6.x is actually currently > "1.6.1pre2 plus N patches" (specifically 163, apparently), which is what > that says.
So, this is more of a problem with the way that we're using git, than a problem with tools that produce a version number. 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. (In the OpenAFS model, we commit first to master, then cherry pick to the 1.6 trunk, then cherry pick to the 1.6.1 branch). One way of fixing this immediate problem would be to commit to master, then cherry pick to the 1.6.1 version branch, then merge back into trunk. We should probably talk about how to fix this before we do the 1.6.2 release. Oh, and master should probably get tagged with something sensible. Cheers, Simon. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
