Re: Release policy question

[Max Bowsher <ma...@ukf.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kfogel@collab.net wrote:
> David Anderson <da...@calixo.net> writes:
> 
>>After a slight mixup in the distribution scripts, the 1.3.0 tarballs have been
>>rerolled.  The new versions, rolled from r17949, are now available (as of 30
>>December 15:00 GMT).
>>
>>http://lolut.utbm.info/pub/subversion-1.3.0/final/
> 
> 
> Policy question:
> 
> 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.)
> 
> 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?


The issue here, is balancing the technical correctness of our version
numbers with the public perception of them.

Having the first real release of 1.3.x being called 1.3.1 would have
been odd. Perhaps what we should have done is to have called the reroll
"1.3.0a" - similar to what Debian did with a tiny bug in sarge, which
resulted in "Debian 3.1r0" followed by "Debian 3.1r0a".


Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFDuVkefFNSmcDyxYARAmTyAJ9VtQOTLFIYQjQQy+a78dH2fbWXMgCg0ubC
5BSScnfYH3KqtqBcQrKG8rg=
=NIkr
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Release policy question

[kf...@collab.net]

Max Bowsher <ma...@ukf.net> writes:
> The issue here, is balancing the technical correctness of our version
> numbers with the public perception of them.

Agreed.

> Having the first real release of 1.3.x being called 1.3.1 would have
> been odd. Perhaps what we should have done is to have called the reroll
> "1.3.0a" - similar to what Debian did with a tiny bug in sarge, which
> resulted in "Debian 3.1r0" followed by "Debian 3.1r0a".

I think people would find that more confusing than just re-releasing
"1.3.0" (I know I would, anyway).

I'm okay with Justin's and Erik's policy suggestion, already posted in
response to my mail.  I'll wait a bit to hear more feedback, then
modify hacking.html accordingly.

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org