[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: <kfogel_at_collab.net>
Date: 2006-02-02 19:52:20 CET

"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.

-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
Received on Thu Feb 2 21:33:03 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.