[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

From: Blair Zajac <blair_at_orcaware.com>
Date: 2006-02-03 04:17:49 CET

On Feb 2, 2006, at 10:52 AM, kfogel@collab.net wrote:

> "Erik Huelsmann" <e.huelsmann@gmx.net> writes:
>> I'm not at all for burning version numbers. I have advocated
>> using .0a for
>> the second release. This has hit some emotional barriers back
>> when we were
>> about to release 1.3.0, as well as it did yesterday on IRC when I
>> re-raised
>> the issue.
>>
>> Though .0a may be meaningless to users, it'd be apparent to
>> everybody (I'd
>> guess) that .0c is the version to use when you have to choose
>> from .0a, .0b
>> and .0c...
>
> Please, not the "a", "b", "c" thing. It doesn't solve the problems
> Greg pointed out: people expect a "clean" number for the first
> release, and if they don't see it, some of them will wonder why
> Conversely, conservative admins may see a "c" release and think it
> represents something significantly more mature than the "a" or ""
> release and upgrade to it, when that's actually not in accord with
> their risk-averse upgrade policy.
>
> We need to face the fact that there are disadvantages to all choices
> here, but also that none of the disadvantages are very severe.
>
> I'm +1 on the "always make a new number" option and on the "it's okay
> to re-use a number in certain rare circumstances" option, but -0 on
> this "a"/"b"/"c" thing. I've not found it particularly helpful when
> I've encountered it in other software.

Agreed. I used to do releases of Orca with that and people would
think that the a=alpha, b=beta, but is not what you want.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 3 04:19:02 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.