[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: <kfogel_at_collab.net>
Date: 2003-12-19 17:09:42 CET

Justin Erenkrantz <justin@erenkrantz.com> writes:
> > Yes, I understand. But Greg's questions 1-5 were not about this kind
> > of build, that's all I'm saying. They were about blessed releases.
> > It's fine to discuss other kinds of builds, but it's confusing to
> > offer them as answers to questions about blessed releases :-).
>
> Well, I think 'unblessed' releases (i.e. from trunk by Joe Random
> developer aka Justin) needs some type of versioning information, too -
> just to provide a point of reference. *I* need version information,
> too.

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.

> 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 :-).

---------------------------------------------------------------------
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:00:39 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.