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

Re: Things you must consider for version numbering

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-12-19 18:17:07 CET

On Fri, 2003-12-19 at 11:09, kfogel@collab.net wrote:
> Yes, I know. Oy vey :-). Everybody agrees on this. Unblessed builds
> should have version numbers. I think so, John thinks so too, Greg
> Hudson thinks so, Kofi Annan thinks so. And all the proposals offered
> meet this criterion, if I recall correctly. Nobody said unblessed
> releases shouldn't have versioning; that's not what my response above
> is saying either.

No, it's not that simple. Justin says that unblessed builds need
release numbers which live in the same version space as blessed release
numbers, so that you know what releases an unblessed build is compatible
with.

My proposal does not have this property, since unblessed releases (and
snapshots and beta builds) are tagged by revision.

Your proposal does not really have this property either. We'd have to
bump the minor version by two each time we added a new function to the
library in order to get the desired property. (Have a careful look at
http://apr.apache.org/versioning.html where it describes "Patch Version"
vs. "Minor Versions".) Or at the very least, each time we released a
trunk snapshot containing new functions. Really, I don't see how
Justin's constraints are compatible with any common version-numbering
system. (You might think Apache uses it, but since as far as I know no
APR project has reached 1.0 yet, they actually have no field experience
with it as far as I know. Also, APR projects have separate projects for
each library, while we do not, which changes the constraints
significantly.)

> > Since there is server/client-compatibility/repository schemas encoded
> > into a version, I think it's critical that everything have a readable
> > version no matter if it is blessed or not. Otherwise, the user has no
> > clue what 'blessed releases' it is compatible with. For example, in
> > the short term, we expect trunk should be 1.0 compatible; long term,
> > we have no idea what 2.0 will mean to users. -- justin
>
> Yes. You may stop fighting this battle. You won. In fact, we were
> all on the same side, and there was no opposition :-).

There most definitely was opposition from me to the idea of keeping the
release version and the shared library versions in sync, and I think the
people who support it don't realize all the ramifications. (Justin
might realize the ramifications, but if he does, he hasn't put forth a
complete proposal yet.)

See http://www.contactor.se/~dast/svn/archive-2003-12/0290.shtml for an
example of opposition.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 18:17:58 2003

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.