Re: Our (in)ability to do releases?

Greg Hudson wrote:
> 2. Our compatibility rules only allow desupport of feature based on the
> (I'll make up terms here) catastrophe model rather than the slow
> extinction model.

It may be worthwhile considering a "punctuated equilibrium" model
instead of either of the extremes you mention, as that might lower the
barrier for major releases to an acceptable level. A focused effort to
move forward at a brisker pace, followed by a quiet period of bugfixes
and more minor feature changes.

The goal should be to make sure that new features can be added in an
orderly fashion without necessarily being frozen out by backwards
compatibility worries. I'm thinking specifically of some of the
discussions about bumping the repository structure to support additional
indexes. As long as that is viewed a "2.0-only task" no development
will happen on trunk.

It's almost like the project has to fork itself into 1.x development
(backwards compatible) and 2.x development (forward compatible only).
If the new development was focused more on this new trunk, 2.x could
become a reality, rather than being a long-off hope. I don't know if
there is enough programming talent available to handle this. But I'd
like to see 2.x last half as long as 1.x did, with more focus on moving
forward than trying to shoehorn new capabilities into the existing
footprint.

John

-- 
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