> -----Original Message----- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 19, 2008 3:54 PM > To: Tapestry development > Subject: Re: Release numbering issues > > > If the "5" is here to stick, perhaps we should move away from the > > traditional MAJOR.MINOR.PATCH scheme. For example, PostgreSQL uses > > something similar to MAJORA.MAJORB.PATCH. E.g., the move from 8.2 to > > 8.3 is considered to be just as major as the move from 7.x to 8.x. > This > > was done, I believe, in an attempt to curb insanely high version > > numbers. > > So, really, 5.MAJOR.MINOR.PATCH? > > I have a *significant* interest in keeping the version number at 5. >
Correct, although I'm suggesting that MINOR could be absorbed into either MAJOR or PATCH in order to prevent inordinately long version numbers. I'd also hate to have to use Tapestry 5.72.x because of constant API additions in a release early, release often system. > > > > Allowing deprecated cruft to amass is clearly going to impact the > > framework. I'd rather see a policy that states a deprecated feature > is > > guaranteed to stick around for maybe 3 minor releases after an > > appropriate replacement is provided. The pitfall here is that the > > number of releases is meant to give ample time for a reasonable > > transition, but may conflict with the notion of releasing early and > > often. A developer shouldn't have to worry about deprecated API > > removals simply because a new minor version was released as the > result > > of an API addition. > > I kind of interpret this as meaning a MAJOR increment means cruft has > fallen out. What I really would like to see is a time-based commitment, but it's meaningless unless there's a regular release schedule. The best you could do is a lower-bound, which I suppose may be good enough. What we want to avoid is forcing people to have to change working code because something was deprecated and the Tapestry team pumped out 3 release with API changes in a two month span. If I had to update my code the way I've had to tracking the 5.0.x releases in a non-cutting-edge system (i.e., to get bugfixes and the occasional new component or two), I'd go mad. The releases after stable should obviously be stable, but I'm giving a taste of what could annoy end users. > This is a good idea whose true usefulness I never previously > appreciated. So we would follow option #2 in trunk, work on 5.1.x, > release more "previews", but when it reaches a stable point, number it > 5.2.0 and start work on 5.3.x (which targets a stable 5.4, etc.) Yeap. That would be the basic idea. All the various API changes would be wrapped up into a monolithic public, stable release when the time is right. If someone wants to track dev in the meanwhile, things would basically progress as they have for the 5.0.x cycle. Otherwise, users get basic get the changes en masse with the next major stable release. Thinking some more, it would make the bugfix backport and deprecated API policies simpler as well. While perhaps the same core issue as I was trying to avoid previously, the presumption is that the major stable release will come far less often than new versions with API changes (i.e., the dev releases). -- Kevin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
