[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: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2003-12-16 08:53:25 CET

--On Sunday, December 14, 2003 12:03 AM -0600 kfogel@collab.net wrote:

> situation. Instead, let's try to concentrate on one line at a time,
> and deviate from that only when a serious bug in a stable release
> demands it.

+1 to your proposal.

I go back to asking that we always have a version number reported in 'svn
--version' even 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.

The problem with adopting an rXXXX-only scheme means that we're back to a
linear ordering. However, I think you *can* map a non-linear ordering on the
x.y.z scheme (by enforcing odd/even rules), but we can't do that with rXXXX.

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

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