[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Release policy question (was: Re: 1.3.0 tarballs up for testing/signing (again))

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2006-01-02 19:25:15 CET

On 1/2/06, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> On Fri, Dec 30, 2005 at 08:01:03PM -0600, kfogel@collab.net wrote:
> > In the past, we had a policy that once a tarball is mentioned in a
> > public forum, that name is used up, and any new tarball must have a
> > new name. But now, two different tarballs have been released into the
> > world under the name "1.3.0". Is this something we discussed and
> > decided we could live with?
> > (Yes, the old policy meant that if there was some problem with 1.3.0,
> > then the first "real" 1.3.x release would be 1.3.1. One purpose of
> > the "-rcX" releases preceding the first ".0" release in a series is to
> > minimize the chance of this happening... but if it did happen, it
> > wasn't supposed to be a disaster. In the old policy, maintaining
> > unambiguous uniqueness was considered most important.)
> Correct.
> > I don't see anything in www/hacking.html or notes/releases.txt to
> > resolve my question. I do recall some discussions in the semi-recent
> > past about this, so maybe we decided to loosen the policy (David's use
> > of "r17949" to disambiguate is an example of why this can work).
> >
> > If we are all agreed that the new policy is
> >
> > "We will try as hard as we can, through the use of RCs, to avoid
> > releasing different tarballs under the same name. But we may
> > still allow it to happen as long as the tarball of that name is
> > still in testing/signing and has not been officially 'blessed'."
> >
> > then I (or someone) can update hacking.html accordingly.
> >
> > Thoughts?
> I would say that if any code changes, it *must* get a new version number.
> If it's just a re-roll due to a dist.sh or packaging problem, then it can
> use the same version number. However, there is never a legitimate reason
> to re-use a version number if the code has actually changed. -- justin

I agree with Justin that this is how I'd like to handle this in this
case: there's no difference in the code shipped, nor is there any
difference in any other significant part of the archive.


Received on Mon Jan 2 19:25:56 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.