William A. Rowe, Jr. wrote:
Martin Sebor wrote:Okay, so just to make sure we're all clear, the process we seem to be converging on goes like this: 1. branch X.Y.Z/ from trunk/ 2. with N starting at 1, tag the X.Y.Z/ branch X.Y.X-rc-N/ and create the corresponding tarball, stdcxx-X.Y.Z-rc-N.tar.gz; vote on tarball 3.1 if the vote passes, rename tarball to stdcxx-X.Y.Z.tar.gz and proceed to publish it 3.2 otherwise, fix problems on the X.Y.Z branch, increment N by 1 and go to 2I like. Is there anyway we can rename branches/x.y.z/ in such a way as to avoid confusing users that it is the final release? E.g. branches/x.y.z-candidate/ ?
I thought you said you were okay with branches/x.y.z/: William A. Rowe, Jr. wrote: > Martin Sebor wrote: > >> [...] I suspect that may not fully >> address your concerns (i.e., the fact that there is a 1.2.3 branch >> before an official release has taken place). > > > I do believe it does, granted the 1.2.3-rc3 branch would be internally > labeled (version id) 1.2.3, but the branch it sits on and the tarballs > it's packaged in both clearly designate 1.2.3-rc3... I'm not dead set against the x.y.z-<suffix> convention but as I said before, I'm not convinced that obfuscating the upcoming version in the name of the branch is necessary. In addition I can imagine situations where the specific "candidate" suffix would be inappropriate. Consider the not so uncommon case where development happens in parallel on two (or more) branches in addition to trunk/. For instance: branches/1.2.3/ <== to be released branches/2.0/ <== future binary incompatible branch Take gcc as an example of this situation: http://gcc.gnu.org/viewcvs/ Currently, in addition to trunk/, development takes place at least on branches/4_0_branch/ and branches/4_1_branch/ (and up until not so long ago the 3_4_branch/ was also active). Certainly, naming the 4.1 branch 4_1_candidate wouldn't be quite right at this point since it's still being actively developed. Assuming we agree to rule out "-candidate" as the suffix, what are we left with? We could use the gcc "-branch" convention but given that the branch lives under branches/ that is clearly superfluous. In my opinion, anyone experienced enough to pull down a branch from Subversion can be expected to "know what they're doing" and we can safely avoid spending cycles preventing them from "accidentally" using unstable code. The rest of our users will grab the release tarball from the download location so there's no risk there. Martin
