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]
