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]
