You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2006/01/12 23:26:52 UTC
[VOTE] publish stdcxx 4.1.3, take 2 (was: Re: Mac OS X and stdcxx)
Justin Erenkrantz wrote:
[...]
>>Since several of them are involved and would require us to recertify
>>the library on all the platforms where it has passed my goal is to get
>>them fixed in 4.1.4. Does that sound reasonable?
>
>
> Sure. Let's just note that Mac OS X isn't supported in the release notes.
Okay, this has been done:
http://svn.apache.org/viewcvs.cgi?rev=368452&view=rev
I also noticed a symbol versioning issue in gcc optimized builds
on Solaris that causes unsats when linking. Since symbol versioning
is still experimental I disabled it on the 4.1.3 branch:
http://svn.apache.org/viewcvs.cgi?rev=368485&view=rev
I created a new tarball incorporating these changes and replaced
the old one with it. Here's the link again for convenience:
http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.1.3.tar.gz
The md5sum for this file is f1bc9bd5ef0966f994a9183e7353176d.
Since these were the only changes I only smoke-tested this new tarball
with gcc 3.2.3 on Linux and gcc 4.0.2 Solaris with successul results.
I hereby cast my +1 vote to publish this tarball :)
I assume everyone else's votes are still good and that we just need
a positive vote from you, Bill, or Ben before we can ask the Incubator
PMC for permission to publish it.
Here's a tally of votes thus far:
+1: 4 + 1 (johnh, lnicoara, ajindal, sebor + willson)
0: none
-1: none
Thanks
Martin
Re: x.y.z numbering and releases
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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
Re: x.y.z numbering and releases
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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
Posted by Martin Sebor <se...@roguewave.com>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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? 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.
Bill
Re: x.y.z numbering and releases
Posted by Martin Sebor <se...@roguewave.com>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Martin Sebor <se...@roguewave.com>.
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.
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
Martin
Re: x.y.z numbering and releases
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.
Re: x.y.z numbering and releases
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Martin Sebor <se...@roguewave.com>.
Justin Erenkrantz wrote:
> --On January 19, 2006 4:29:33 PM -0700 Martin Sebor
> <se...@roguewave.com> wrote:
>
>> 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 mv tags/1.2.3-not-an-official-release-yet tags/1.2.3
Nifty -- thanks! :)
>
> Again, my take is that a release candidate is not a good idea; instead,
> I feel you should just burn the number. But, if you insist on a rc
> process, some ASF projects have done that with varying measure of success.
>
>> 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.
>
>
> The critical point of the ASF's release policy is that there are at
> least three PMC members voting +1 and that there are more positive than
> negative votes. A RM will create a release individually, but in order
> to distribute the release and call it Apache XYZ, it needs the approval
> of the PMC (as denoted by their votes). The specifics of how each
> project gets to that is up to each PMC.
>
> The concern I had with your earlier comments was altering the source,
> assuming all of the prior votes counted, and not having any
> identification to know that the source had changed. That's dangerous
> behavior because it facilitates confusion over what we're all voting on
> and what users will download. -- justin
I see. It was a mistake caused by my inexperience with the ASF
release process. I certainly agree and understand that it needs
to be avoided and why. I will keep it in mind for the next release
(although I hope to do a better job of making sure that the first
tarball is good to begin with! :)
Thanks again for your helpful comments!
Martin
Re: x.y.z numbering and releases
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On January 19, 2006 4:29:33 PM -0700 Martin Sebor <se...@roguewave.com>
wrote:
> 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 mv tags/1.2.3-not-an-official-release-yet tags/1.2.3
Again, my take is that a release candidate is not a good idea; instead, I
feel you should just burn the number. But, if you insist on a rc process,
some ASF projects have done that with varying measure of success.
> 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.
The critical point of the ASF's release policy is that there are at least
three PMC members voting +1 and that there are more positive than negative
votes. A RM will create a release individually, but in order to distribute
the release and call it Apache XYZ, it needs the approval of the PMC (as
denoted by their votes). The specifics of how each project gets to that is
up to each PMC.
The concern I had with your earlier comments was altering the source,
assuming all of the prior votes counted, and not having any identification
to know that the source had changed. That's dangerous behavior because it
facilitates confusion over what we're all voting on and what users will
download. -- justin
Re: x.y.z numbering and releases
Posted by Martin Sebor <se...@roguewave.com>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Martin Sebor wrote:
> Justin Erenkrantz wrote:
>
>> --On January 18, 2006 5:30:04 PM -0700 Martin Sebor
>> <se...@roguewave.com> 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
>
> I understand the motivation behind the policy and fully support
> the goal of preventing the problem it is designed to address.
>
> 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.
Re: x.y.z numbering and releases
Posted by Martin Sebor <se...@roguewave.com>.
Justin Erenkrantz wrote:
> --On January 18, 2006 5:30:04 PM -0700 Martin Sebor
> <se...@roguewave.com> 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
I understand the motivation behind the policy and fully support
the goal of preventing the problem it is designed to address.
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.
Martin
Re: x.y.z numbering and releases
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On January 18, 2006 5:30:04 PM -0700 Martin Sebor <se...@roguewave.com>
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
Posted by Martin Sebor <se...@roguewave.com>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Martin Sebor wrote:
> William A. Rowe, Jr. wrote:
>
>> 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.
The candidate and number are pitched. We have a mantra,
"version numbers are cheap".
>> 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.
>
> 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.
> 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.
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.
Bill
Re: x.y.z numbering and releases
Posted by Martin Sebor <se...@roguewave.com>.
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
x.y.z numbering and releases
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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>.
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.
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, 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.
Bill
Re: [VOTE] publish stdcxx 4.1.3, take 2
Posted by Martin Sebor <se...@roguewave.com>.
Justin Erenkrantz wrote:
> --On January 12, 2006 3:26:52 PM -0700 Martin Sebor
> <se...@roguewave.com> wrote:
>
>> I created a new tarball incorporating these changes and replaced
>> the old one with it. Here's the link again for convenience:
>> http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.1.3.tar.gz
>> The md5sum for this file is f1bc9bd5ef0966f994a9183e7353176d.
>>
>> Since these were the only changes I only smoke-tested this new tarball
>> with gcc 3.2.3 on Linux and gcc 4.0.2 Solaris with successul results.
>> I hereby cast my +1 vote to publish this tarball :)
>
>
> +1 with Solaris 10/Forte 11.
>
> The test cases say everything 'failed', but I'm not sure that it isn't
> really a false positive. It looks okay otherwise as far as I can tell.
Assuming the failures came out of invoking make run they are bogus.
We've changed the output of the ported tests but haven't changed
the infrastructure to recognize the new ouptut. Running some of
the tests manually should confirm this.
>
>> I assume everyone else's votes are still good and that we just need
>> a positive vote from you, Bill, or Ben before we can ask the Incubator
>> PMC for permission to publish it.
>
>
> Nope. Typically, any changes to the code contained in a release
> invalidates all previous votes. Nice try. =)
Okay, I'll collect new votes from the original voters and keep this
rule in mind in the future.
>
> 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.
Thanks!
Martin
Re: [VOTE] publish stdcxx 4.1.3, take 2 (was: Re: Mac OS X and
stdcxx)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On January 12, 2006 3:26:52 PM -0700 Martin Sebor <se...@roguewave.com>
wrote:
> I created a new tarball incorporating these changes and replaced
> the old one with it. Here's the link again for convenience:
> http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.1.3.tar.gz
> The md5sum for this file is f1bc9bd5ef0966f994a9183e7353176d.
>
> Since these were the only changes I only smoke-tested this new tarball
> with gcc 3.2.3 on Linux and gcc 4.0.2 Solaris with successul results.
> I hereby cast my +1 vote to publish this tarball :)
+1 with Solaris 10/Forte 11.
The test cases say everything 'failed', but I'm not sure that it isn't
really a false positive. It looks okay otherwise as far as I can tell.
> I assume everyone else's votes are still good and that we just need
> a positive vote from you, Bill, or Ben before we can ask the Incubator
> PMC for permission to publish it.
Nope. Typically, any changes to the code contained in a release
invalidates all previous votes. Nice try. =)
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.
HTH. -- justin
[PING] Re: [VOTE] publish stdcxx 4.1.3, take 2
Posted by Martin Sebor <se...@roguewave.com>.
Justin, Bill & Ben:
Have you had a chance to check out the latest tarball? If so,
your vote would be greatly appreciated so that we can proceed
with the request to publish the tarball on general@incubator.
Thanks!
Martin
Martin Sebor wrote:
> Justin Erenkrantz wrote:
> [...]
>
>>> Since several of them are involved and would require us to recertify
>>> the library on all the platforms where it has passed my goal is to get
>>> them fixed in 4.1.4. Does that sound reasonable?
>>
>>
>>
>> Sure. Let's just note that Mac OS X isn't supported in the release
>> notes.
>
>
> Okay, this has been done:
> http://svn.apache.org/viewcvs.cgi?rev=368452&view=rev
>
> I also noticed a symbol versioning issue in gcc optimized builds
> on Solaris that causes unsats when linking. Since symbol versioning
> is still experimental I disabled it on the 4.1.3 branch:
> http://svn.apache.org/viewcvs.cgi?rev=368485&view=rev
>
> I created a new tarball incorporating these changes and replaced
> the old one with it. Here's the link again for convenience:
> http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.1.3.tar.gz
> The md5sum for this file is f1bc9bd5ef0966f994a9183e7353176d.
>
> Since these were the only changes I only smoke-tested this new tarball
> with gcc 3.2.3 on Linux and gcc 4.0.2 Solaris with successul results.
> I hereby cast my +1 vote to publish this tarball :)
>
> I assume everyone else's votes are still good and that we just need
> a positive vote from you, Bill, or Ben before we can ask the Incubator
> PMC for permission to publish it.
>
> Here's a tally of votes thus far:
>
> +1: 4 + 1 (johnh, lnicoara, ajindal, sebor + willson)
> 0: none
> -1: none
>
> Thanks
> Martin
Re: [VOTE] publish stdcxx 4.1.3, take 2
Posted by Liviu Nicoara <ni...@roguewave.com>.
+1
Tested on RH AS 4 Itanium, EM64T, and SUSE (x86) (all with gcc).
Martin Sebor wrote:
> Justin Erenkrantz wrote:
> [...]
>
>>>Since several of them are involved and would require us to recertify
>>>the library on all the platforms where it has passed my goal is to get
>>>them fixed in 4.1.4. Does that sound reasonable?
>>
>>
>>Sure. Let's just note that Mac OS X isn't supported in the release notes.
>
>
> Okay, this has been done:
> http://svn.apache.org/viewcvs.cgi?rev=368452&view=rev
>
> I also noticed a symbol versioning issue in gcc optimized builds
> on Solaris that causes unsats when linking. Since symbol versioning
> is still experimental I disabled it on the 4.1.3 branch:
> http://svn.apache.org/viewcvs.cgi?rev=368485&view=rev
>
> I created a new tarball incorporating these changes and replaced
> the old one with it. Here's the link again for convenience:
> http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.1.3.tar.gz
> The md5sum for this file is f1bc9bd5ef0966f994a9183e7353176d.
>
> Since these were the only changes I only smoke-tested this new tarball
> with gcc 3.2.3 on Linux and gcc 4.0.2 Solaris with successul results.
> I hereby cast my +1 vote to publish this tarball :)
>
> I assume everyone else's votes are still good and that we just need
> a positive vote from you, Bill, or Ben before we can ask the Incubator
> PMC for permission to publish it.
>
> Here's a tally of votes thus far:
>
> +1: 4 + 1 (johnh, lnicoara, ajindal, sebor + willson)
> 0: none
> -1: none
>
> Thanks
> Martin
>