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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 2 17:26:07 2006