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]
