Re: x.y.z numbering and releases
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 2 I 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
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: Martin Sebor wrote: William A. Rowe, Jr. 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/ == current development of 1.2 branches/1.2.3/ == to be released branches/2.0/ == future binary incompatible branch Did I understand this correctly? Yes. If so, yes I can agree that -candidate might be overkill. Let's consider, it's really no different if someone picks up 1.2.3 and sends us some report about it, than if they pick up the 1.2 branch and report an issue. Since tags/ is where to look for a specific release, and most folks do know that branches/ are dynamic points in time, I guess my concern is unfounded. Yes. I think it's a matter of clearly documenting the branching (and versioning) policy and the release process rather than trying to come up with a foolproof naming convention. Martin
Re: x.y.z numbering and releases
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 2 I 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/ ? When x.y.z is released, the original branches/x.y.z-candiate tree can be svn rm'ed. Bill
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: Martin Sebor wrote: [...] However, I believe that the issue can be just as effectively dealt with by implementing the -rcN (or similar) suffix policy that Bill mentioned in his first post, with the additional (and IMO essential) advantage of preserving the well-established meaning of the version number grounded in precisely defined technical criteria. I agree with Martin -if- the SVN tag is also designated tags/1.2.3-rcN until it's voted in, and then copied or renamed to tags/1.2.3 upon release. I have no objection to tagging the 1.2.3 branch 1.2.3-rcN for each tarball that's about to be voted on but 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). If there is an easy way to rename a branch I suppose we could start with a 1.2.3-not-an-official-release-yet (or whatever) branch and, once the release is approved, rename it to 1.2.3. But I feel that this seems like going too far. I have been following several open source projects for years (e.g., gcc, glibc, GNU make, STLport) but this is the first time I've ever even heard of this policy. Do you know of any projects outside the ASF that use it? If not, I wonder what it is about the ASF that makes us different from the other open source projects and that requires us to adopt such an unconventional policy. Martin
Re: x.y.z numbering and releases
Martin Sebor wrote: I have no objection to tagging the 1.2.3 branch 1.2.3-rcN for each tarball that's about to be voted on but 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. This resolves Justin's concern about rerolling the tarball, and addresses your concern that like several other Apache packages, you would like to have several review cycles. If there is an easy way to rename a branch I suppose we could start with a 1.2.3-not-an-official-release-yet (or whatever) branch and, once the release is approved, rename it to 1.2.3. svn rm? It's a lovely thing :) It would even point the file renamed back at the branch it originated from (documenting that yes, in fact the -rc3 candidate became official.) I wonder what it is about the ASF that makes us different from the other open source projects and that requires us to adopt such an unconventional policy. It's not, this isn't ASF policy, it's the original httpd committer's policy, so don't be surprized by Roy or others chiming in that there is only one right way :) It's been that way in httpd-land forever. But that doesn't mean that projects can't adopt, with appropriate safeguards against confusion, policies that match their own style. Bill
Re: x.y.z numbering and releases
On Fri, Jan 20, 2006 at 01:39:36AM -0600, William A. Rowe, Jr. wrote: William A. Rowe, Jr. wrote: 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. they designate 1.2.3-rc3!!! Only the internal directory path within the tarball and appropriate header files omit the -rc3 desigation, such that... This resolves Justin's concern about rerolling the tarball, and addresses your concern that like several other Apache packages, you would like to have several review cycles. Thought you were missing a key phrase or two. =) -- justin
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: Martin Sebor wrote: Justin Erenkrantz wrote: In the future, you should not reuse the version - therefore, this should really be 4.1.4. Once, 4.1.3 is posted, it's 'gone' (regardless of whether it passes or not). Therefore, a vote should be with respect to a specific tarball. If that tarball changes (and a new version is pushed out), you need to get the minimum 3 +1s on that specific tarball. This is an interesting policy that I think deserves to be discussed further. Let me comment on it in a separate thread so as not to detract from the vote. Absolutely not ;-) Here's your thread for discussion of numbering, going forwards... In the httpd project, the RM (release manager) tags a build, with the final version number. If that tarball changes after it leaves their hands, and is in the hands of testers, it's never modified (much) sigh. I'm not sure this means that the httpd version of the new tarball stays the same or not if the old tarball fails to get an approval. Some ASF projects roll a -pre1 or -rc1 tarball. It's clear to the user who downloads it that this is almost it, and is being voted on. If they don't get cleared, lets say three files change, then they roll -pre2 or -rc2. That seems like a reasonable policy to distinguish the tarballs. Let me write up something along these lines for stdcxx and post it for review. Now... in fairness Justin is right; you must vote on the actual tarball you will ship. You can't make an incremental change and consider the old votes still valid. Heck, maybe those voters even disagree with the suggested change, or how it was packaged? But please consider, the candidate must be clearly named. We have to be able to determine that Joe, Sandy and Pat all voted +1 on the -same tarball-. If we do that with -pre1/-pre2 or -rc1/-rc2, or as httpd does with x.y.z (ditched or adopted as appropriate), it doesn't so much matter. It really matters that we 1) know what people voted on, Understood. and 2) know what bugs people are pointing at. If there are several x.y.z packages all identically named, it's harder to know that the reporter is pointing at something that's already fixed, newly broken, or not working the entire cycle. I agree. My concern with changing the version number during a release is technical rather than procedural. A library version number must reflect both the backward and forward (source and binary) compatibility between any two releases of the library. The rules for assigning the major, minor, and micro (or patch, when permitted by the system linker) numbers are precisely specified and correspond to well-defined changes with an impact on the different types of compatibility (see the rules in effect for the Rogue Wave C++ Standard library below). There is typically no allowance in these rules for making version changes that are not determined by changes and differences between actual code releases. The version number should also be an indicator of continuity (or its lack) between releases of the library. Users of the latest release of a library should be able to decide whether to upgrade to the new fully compatible release without having to wonder what they might have missed in the releases in between or whether a prior release might be sufficient or safer. Martin The Rogue Wave C++ Standard Library versioning policy: The version identifier of a library is typically defined as the string major.minor.micro with the following semantics: The major number starts at 1 and is incremented by one for each new release of the library that is source or binary incompatible with the previous release. Incrementing the major number resets both the minor and micro numbers to 0. The minor number starts at 0 and is incremented by one for each new release of the library that is forward but not backward compatible with the previous release. Incrementing the minor number resets the micro number to 0. The micro number starts at 0 and is incremented by one for each new release of the library that contains source code changes that are backward compatible with the previous release. A couple of useful references on library and symbol versioning: http://www.usenix.org/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/ http://sources.redhat.com/autobook/autobook/autobook_91.html
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: [...] The candidate and number are pitched. We have a mantra, version numbers are cheap. Thanks for the clarification. [...] There is typically no allowance in these rules for making version changes that are not determined by changes and differences between actual code releases. Yes, and in fact (unless something went HORRIBLY wrong) the never released version 1.2.3 enjoys versioning compatibility with 1.2.2 and 1.2.4 per the project's policy. It just simply never existed. True. The only snag here is that our existing policy deliberately prevents this from happening. [...] You can argue the converse; treating each and every release as equally stable doesn't help the user. Stating 'whoops, 1.2.3 just wasn't up to par, so we've released 1.2.4 following 1.2.2' gives the user one reassurance; the bad releases don't make it out the door. I don't think of the name of a file mentioned in emails as a release, least of all when it refers to a transient file in someone's home directory. Similarly, I don't consider an SVN branch to be an actual release, even if its contents were identical to it. With this mindset I can only see one potential effect of skipping versions on users -- that of confusion. That said, if sticking some suffix (such as -rcN) at the end of the release candidate tarball helps dispel even the slightest concern of mistaking a pre-release tarball for the real thing, I will gladly support doing so within the stdcxx release policy. As always, thanks for the feedback! Martin
Re: x.y.z numbering and releases
--On January 18, 2006 5:30:04 PM -0700 Martin Sebor [EMAIL PROTECTED] wrote: I don't think of the name of a file mentioned in emails as a release, least of all when it refers to a transient file in someone's home directory. Similarly, I don't consider an SVN branch to be an actual release, even if its contents were identical to it. With this mindset I can only see one potential effect of skipping versions on users -- that of confusion. One of the problems in working in open-source projects is that everyone can see the release immediately. Therefore, we don't have the ability to 'take' a release back - once you tag it or announce it in any public forum, it's gone. By enforcing a 'cheap' version number policy, we remove any confusion: were they using the '1.2.3' release from Jan 10 or was that the '1.2.3' release from Jan 15? Instead, we make it crystal clear what the release was by only allowing that version to be used once. -- justin
Re: x.y.z numbering and releases
On Wed, Jan 18, 2006 at 09:45:54PM -0700, Martin Sebor wrote: However, I believe that the issue can be just as effectively dealt with by implementing the -rcN (or similar) suffix policy that Bill mentioned in his first post, with the additional (and IMO essential) advantage of preserving the well-established meaning of the version number grounded in precisely defined technical criteria. It's still just as precisely defined technically (go look at APR's versioning guidelines[1]). The real point of a release is whether we (as a PMC) 'bless' it by saying it passes all of the standard Apache release procedures. The real problem you have with rc sequences is that you end up having to vote twice for a release as you need to change the tarballs to go from an rc to a final release. It's almost never worth the hassle, IMHO. -- justin 1. http://apr.apache.org/versioning.html
