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

Re: Expected post-1.0 release cycle?

From: John Peacock <jpeacock_at_rowman.com>
Date: 2003-12-23 16:41:04 CET

Greg Hudson wrote:
> In your world, I guess we might have released (let's assume even/odd
> here, since it's your world) svn 1.2.0, svn 1.4.0, and svn 1.6.0 by
> then, and 1.6.x is the only release we'll make bugfixes to.

I don't know why you keep talking about skipped stable versions, since it does
not correspond to the reality of pre-1.0 releases, nor does it necessarily
correspond to post-1.0 development releases. The whole thrust of the
development track is to push the program in directions that are _not_ compatible
with the production release, because of features we couldn't get done before the
release, or things that no one even thought of at the time.

Pre-1.0, we are promising only that client 0.x+1 will work with server 0.x.
There have been three schema changes, countless API and ABI changes, etc. It is
true that pre-1.0 we have been free to do that, since in a real sense there is
nothing set in stone until that magic 1.0 release.

However, once 1.0 is out the door, there is nothing preventing the development
track to follow the exact same model as the pre-1.0 development. Each
development release comes out after ~3 weeks and the only promise is that each
release is completely compatible with the one before it. The dev version is
simply incremented as "dev releases" are made.

Thus, in Sept 2004, the production version will be at 1.0.3 (some bugfixes) and
the development track will be at 1.1.23 (or whatever). At this point, a 1.2.0
branch is cut (from the head of the dev track) and will contain incompatible
changes from the 1.0.x release. Then, when 1.2.0 is golden, 1.3.0 becomes the
new dev track.

The public major/minor/patch model does not have to (and I would argue
shouldn't) constrain the development of the next production release. The odds
are very good that the dev releases will also be nearly backwards compatible
with the latest production release, too. But the reverse will rarely be true,
in practice. The only thing that matters is that the _public_ releases meet
those criteria...


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 23 16:41:29 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.