I'm for odd/even approach too :) On Feb 19, 2008 9:59 PM, Robert Zeigler <[EMAIL PROTECTED]> wrote: > +1 on the odd/even approach (not that we're voting, but...) > > Robert > > > On Feb 19, 2008, at 2/192:53 PM , Howard Lewis Ship wrote: > > > On Feb 19, 2008 12:35 PM, Kevin Menard <[EMAIL PROTECTED]> wrote: > >> I'm going to have to chew this over some more because there are some > >> pretty important ramifications here. This is more a stream of > >> thoughts. > >> > >> 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. > > > >> > >> 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. > > > >> > >> Likewise, we don't want to force someone to have to upgrade to a > >> new API > >> in order get a bugfix. Drawing from my experience with T4, the > >> upgrade > >> to T4.1 was not nearly as smooth as I would have hoped for, but was > >> necessitated due to bug fixes only being available on that line. Of > >> course, parallel branch development is unduly harsh on a group of > >> volunteer contributors. > >> > >> The old even-odd system may be interesting to look at, too. 5.1.x is > >> unstable and all bets are off. 5.2 is the stable version, with 5.2.x > >> being bugfixes. 5.3.x becomes the next development branch. It may > >> strike a nice compromise between version diarrhea and API stability, > >> while allowing the dev team to produce quality releases with minimal > >> hoop jumping. > > > > 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.) > > > >> > >> -- > >> Kevin Menard > >> Servprise International, Inc. > >> Remote reboot & power control for your network > >> www.servprise.com +1 508.892.3823 x308 > >> > >> > >> > >>> -----Original Message----- > >>> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > >>> Sent: Tuesday, February 19, 2008 2:38 PM > >>> To: Tapestry development > >>> Subject: Release numbering issues > >>> > >>> Tapestry 5 is, in my opinion, nearing the point where a stable > >>> release > >>> is appropriate. > >>> > >>> Once Tapestry 5 does reach stable, we will need to careful guard > >>> backwards compatibility, and to express that backwards compatibility > >>> in the version number. > >>> > >>> I've started keeping a log of changes that may affect people > >>> upgrading > >>> from one release to another: > >>> > >> http://tapestry.formos.com/nightly/tapestry5/tapestry-core/upgrade.html > >>> > >>> The Apache Portable Runtime includes some useful guidelines: > >>> http://apr.apache.org/versioning.html > >>> > >>> MAJOR.MINOR.PATCH > >>> > >>> MAJOR is a major API changes, such as Tapestry 4 to Tapestry 5. > >>> Let's > >>> just say that's staying at "5", regardless what some dickless troll > >>> says. > >>> > >>> The pain of things is that removing something is forbidden without a > >>> major API change. Deprecate, yes. Remove, no. That also means > >>> maintaining compatibility; so when you deprecate, you must keep the > >>> old implementation and juggle it in terms of the new implementation. > >>> > >>> MINOR represents additions to the APIs. It is incremented when > >>> adding > >>> a new public interface (annotation, class, component, etc.), or > >>> adding > >>> a method to a new public interface. > >>> > >>> PATCH means no API change at all, it means binary compatibility. > >>> Really, it means existing code can be upgraded without even a > >>> recompile. End users should be able to switch between releases the > >>> with same MAJOR.MINOR number with the expectation that nothing > >>> breaks. > >>> > >>> At some point, some version of Tapestry is going to be the release > >>> candidate, say Tapestry 5.0.12. If it survives in the wild for a > >>> period of time (a few weeks?) we can then vote it the final release > >>> and update the Tapestry project site ... there will be links > >>> identifying the stable version of Tapestry on the main page, and on > >>> the downloads page. > >>> > >>> Option #1: Add a sub-patch number. > >>> > >>> So let's assume that 5.0.12 is out there and there's a release > >>> branch. > >>> Meanwhile, work is proceeding on new features in the trunk (with a > >>> version number of 5.0.13-SNAPSHOT). > >>> > >>> If there's a bug in 5.0.12 that we want to fix, I would propose that > >>> the work occurs in the 5.0.12 branch and that we create a new > >>> release > >>> candidate: 5.0.12.1. > >>> Alternate: 5.0.12a. > >>> > >>> Meanwhile, work continues on 5.0.13-SNAPSHOT, but when someone > >>> changes > >>> an API, the number immediately jumps to 5.1.0-SNAPSHOT. > >>> > >>> Option #2: Assume an API change after a release > >>> > >>> Trunk immediately jumps to 5.1.0-SNAPSHOT. Problems in the 5.0.12 > >>> release candidate are fixed as 5.0.13. Problem: what if the release > >>> candidate requires an API change as part of a bug fix? > >>> > >>> I think this might be the way to go, the easiest to manage. > >>> > >>> THOUGHTS > >>> > >>> You might understand, in this context, why I've been doing some > >>> refactoring now, as it's in some ways the "last chance". > >>> > >>> I purposely laid out the public vs. internal structure so that > >>> backwards compatibility would be achievable. People should not have > >>> an expectation that any code that imports anything from an internal > >>> package will be PATCH compatible. > >>> > >>> TapestryModule is a grey area, as it defines both public and private > >>> services. Again, a private service will be in an internal package > >>> and > >>> therefore not covered by backwards compatibility. > >>> > >>> Components are going to be tricky, as they don't have an public > >>> interface to hide behind. Changes to components. > >>> > >>> While 5.1.x is under development, to we run it as I've been running > >>> 5.0.x? I.e., just patch number changes regardless. In other words, > >>> is backwards compatibility, as reflected in version numbers, > >>> something > >>> that applies to every publically available release, or only to final > >>> stable releases? I would tend toward the latter ... 5.1.x and 5.1.y > >>> may not be API compatible but that's ok, they're alpha. > >>> > >>> Should we incorporate alpha into the version number? 5.1- > >>> ALPHA.x? Or > >>> just have a release matrix on the project site that states "5.0.12 > >>> is > >>> stable, 5.1.x is currently alpha". > >>> > >>> If we assume that Option #2 is the way to go, I can change the > >>> release > >>> number in JIRA from "5.0 Next Release" to "5.1". > >>> > >>> -- > >>> Howard M. Lewis Ship > >>> > >>> Creator Apache Tapestry and Apache HiveMind > >>> > >> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > -- > > Howard M. Lewis Ship > > > > Creator Apache Tapestry and Apache HiveMind > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
