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

Re: version numbering (was: 0.35 => Beta => 1.0 schedule)

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-12-16 16:52:10 CET

On Tue, 2003-12-16 at 02:53, Justin Erenkrantz wrote:
> I go back to asking that we always have a version number reported in 'svn
> --version' even on the trunk.

But unless we change this number with every commit, such a version
number would be vague at best and deceptive at worst. A user reports
that their "svn --version" says 1.1.13, but it's not actually the 1.1.13
tarball we put out, but a similar version on the trunk.

> As I've said before, Greg H's suggestion
> doesn't allow for a version number to be reported, and I think that's a
> horribly frustrating scheme to work with as a user. Depending upon if you are
> on 'stable' or 'unstable', you will either get a x.y.z or rXXXX. I think it
> must be consistent.

Why? And, how many users do we really expect to be working with the
trunk at all? I think you're expecting life after 1.0 to be more
similar to life before 1.0 than it really will be.

> I dislike Mozilla's version scheme as I have no idea what's changed between
> 1.5 and 1.6. Is it a big change? Little change? With Linux-based schemes, I
> can quickly know that 2.4->2.6 is bound to be a 'large-ish' change with
> testing (2.5) in between. -- justin

This argument seems especially specious. Why is the difference between
Linux 2.4 and Linux 2.6 inherently any larger than the diference between
Mozilla 1.5 and Mozilla 1.6?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 16 16:52:57 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.