You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2008/02/19 20:37:57 UTC
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Release numbering issues
Posted by Christian Edward Gruber <ch...@gmail.com>.
I'd recommend option #2, and then don't do 5.1.0 until release. have
5.1-SNAPSHOT be the internal version regardless, but have alphas and
betas until release, then use the z (patch) number for bugfixes while
you work on 5.2-SNAPSHOT.
Cheers,
Christian.
On 19-Feb-08, at 14:37 , Howard Lewis Ship wrote:
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Release numbering issues
Posted by Davor Hrg <hr...@gmail.com>.
I'm for odd/even approach too :)
On Feb 19, 2008 9:59 PM, Robert Zeigler <ro...@scazdl.org> 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 <km...@servprise.com> 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:hlship@gmail.com]
> >>> 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: dev-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator Apache Tapestry and Apache HiveMind
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Release numbering issues
Posted by Christian Edward Gruber <ch...@gmail.com>.
So essentially it's
ARCH.MAJOR.MINOR.PATCH or REWRITE.MAJOR.MINOR.PATCH
insofar as the Architecture of 5 is different from 4, though the
concepts are related.
I don't know, I just see minor and patch to be somewhat too closely
related, or at least they should be. 5.1.1->5.1.2 could be a bugfix
or an implementation change if it is purely internal or has no API
impact, 5.1.x -> 5.2 would be API additive, but could also be a bugfix
or a feature. 5.x -> 6.x just wouldn't happen. I think this is
possible as long as .z level features don't stew in the pot too long
and releases are reasonably regular. The only difference would really
be that a bugfix might result in a quick shuffle to release sooner,
possibly even grabbing from a previous tag and branching to get the
fix out sooner so as not to polute the "fix" with new code, then just
rev the snapshot version currently on the trunk and merge the isolated
change in if it's still relevant. There's not a huge core-committers
list here, so I'm thinking it's manageable.
Christian.
On 19-Feb-08, at 18:21 , Ulrich Stärk wrote:
> I think http://commons.apache.org/releases/versioning.html is a good
> guide to what I mean and it doesn't seem that uncommon at the ASF
> (from a quick scan at least Struts, commons and OpenJPA use it). The
> only difference is that we prepend 5 to the major number.
>
> Uli
>
> Ulrich Stärk schrieb:
>> I agree that my proposal demands some discipline from the developers.
>> But as a user I want to have new features and improvements now. And
>> not with the next stable release. And I want to have them without
>> having to rework everything I have done so far. (You know, we are
>> like children :-))
>> I once learned that time to market of a product is crucial for its
>> success. When you always wait with new features until the next
>> stable release and then also reserve the right to introduce API
>> incompatibilities within that same release you are forcing your
>> users to either use unstable software or drive them away completely
>> to one of your competitors.
>> I really urge you to weigh up the effort needed to coordinate a
>> small bunch of developers against the benefit of being able to
>> release new features with the guarantee to not introduce API
>> incompatibilities.
>> 5.MAJOR.MINOR.PATCH is my favorite with MAJOR changing when
>> introducing API incompatiblities and MINOR when adding new features.
>> Uli
>> Kevin Menard schrieb:
>>> While I can appreciate that the kernel devs found the odd/even
>>> didn't
>>> work for them, as a user I appreciated it more.
>>>
>>> That's neither here nor there, though. From a pragmatic standpoint,
>>> the A.B.C.D scheme, aside from being really long, makes POM
>>> management a pain. If Howard has one idea of what he's going to do
>>> next and I have another and Ted has a totally different one, we'll
>>> run into people bumping B, C, or D. At best you end up with a bunch
>>> of confusing version bumps. At worst, someone forgets to make the
>>> bump (and this will happen), so 5.B.C+1-SNAPSHOT ends up containing
>>> an API incompatibility that should have really been in
>>> 5.B+1-SNAPSHOT. Now, I'll concede that SNAPSHOTs are subject to
>>> breakage, but they shouldn't be so foolishly.
>>>
>>> If these concerns can be allayed using another method, I'm open to
>>> it. As I've said earlier, it's a non-trivial matter to consider, so
>>> the more quality suggestions, the better.
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Release numbering issues
Posted by Ulrich Stärk <ul...@spielviel.de>.
I think http://commons.apache.org/releases/versioning.html is a good
guide to what I mean and it doesn't seem that uncommon at the ASF (from
a quick scan at least Struts, commons and OpenJPA use it). The only
difference is that we prepend 5 to the major number.
Uli
Ulrich Stärk schrieb:
> I agree that my proposal demands some discipline from the developers.
>
> But as a user I want to have new features and improvements now. And not
> with the next stable release. And I want to have them without having to
> rework everything I have done so far. (You know, we are like children :-))
>
> I once learned that time to market of a product is crucial for its
> success. When you always wait with new features until the next stable
> release and then also reserve the right to introduce API
> incompatibilities within that same release you are forcing your users to
> either use unstable software or drive them away completely to one of
> your competitors.
>
> I really urge you to weigh up the effort needed to coordinate a small
> bunch of developers against the benefit of being able to release new
> features with the guarantee to not introduce API incompatibilities.
>
> 5.MAJOR.MINOR.PATCH is my favorite with MAJOR changing when introducing
> API incompatiblities and MINOR when adding new features.
>
> Uli
>
> Kevin Menard schrieb:
>> While I can appreciate that the kernel devs found the odd/even didn't
>> work for them, as a user I appreciated it more.
>>
>> That's neither here nor there, though. From a pragmatic standpoint,
>> the A.B.C.D scheme, aside from being really long, makes POM
>> management a pain. If Howard has one idea of what he's going to do
>> next and I have another and Ted has a totally different one, we'll
>> run into people bumping B, C, or D. At best you end up with a bunch
>> of confusing version bumps. At worst, someone forgets to make the
>> bump (and this will happen), so 5.B.C+1-SNAPSHOT ends up containing
>> an API incompatibility that should have really been in
>> 5.B+1-SNAPSHOT. Now, I'll concede that SNAPSHOTs are subject to
>> breakage, but they shouldn't be so foolishly.
>>
>> If these concerns can be allayed using another method, I'm open to
>> it. As I've said earlier, it's a non-trivial matter to consider, so
>> the more quality suggestions, the better.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Release numbering issues
Posted by Kevin Menard <km...@servprise.com>.
Since nothing has been set in stone yet, there's no reason that a new feature couldn't be backported to the "patch" level. The only thing I think that has really been decided is that a patch level update shouldn't change any public interfaces.
I do think you're arguing both sides of the same coin, though. More overhead in creating releases, by its very nature, will slow down the release process. In an ideal world, that wouldn't be the case, but preparing a release is a headache as it stands. I'm not sure the method you've proposed would make it any simpler.
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for your network
www.servprise.com +1 508.892.3823 x308
> -----Original Message-----
> From: Ulrich Stärk [mailto:uli@spielviel.de]
> Sent: Tuesday, February 19, 2008 5:57 PM
> To: Tapestry development
> Subject: Re: Release numbering issues
>
> I agree that my proposal demands some discipline from the developers.
>
> But as a user I want to have new features and improvements now. And not
> with the next stable release. And I want to have them without having to
> rework everything I have done so far. (You know, we are like children
> :-))
>
> I once learned that time to market of a product is crucial for its
> success. When you always wait with new features until the next stable
> release and then also reserve the right to introduce API
> incompatibilities within that same release you are forcing your users
> to
> either use unstable software or drive them away completely to one of
> your competitors.
>
> I really urge you to weigh up the effort needed to coordinate a small
> bunch of developers against the benefit of being able to release new
> features with the guarantee to not introduce API incompatibilities.
>
> 5.MAJOR.MINOR.PATCH is my favorite with MAJOR changing when introducing
> API incompatiblities and MINOR when adding new features.
>
> Uli
>
> Kevin Menard schrieb:
> > While I can appreciate that the kernel devs found the odd/even didn't
> > work for them, as a user I appreciated it more.
> >
> > That's neither here nor there, though. From a pragmatic standpoint,
> > the A.B.C.D scheme, aside from being really long, makes POM
> > management a pain. If Howard has one idea of what he's going to do
> > next and I have another and Ted has a totally different one, we'll
> > run into people bumping B, C, or D. At best you end up with a bunch
> > of confusing version bumps. At worst, someone forgets to make the
> > bump (and this will happen), so 5.B.C+1-SNAPSHOT ends up containing
> > an API incompatibility that should have really been in
> > 5.B+1-SNAPSHOT. Now, I'll concede that SNAPSHOTs are subject to
> > breakage, but they shouldn't be so foolishly.
> >
> > If these concerns can be allayed using another method, I'm open to
> > it. As I've said earlier, it's a non-trivial matter to consider, so
> > the more quality suggestions, the better.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Release numbering issues
Posted by Ulrich Stärk <ul...@spielviel.de>.
I agree that my proposal demands some discipline from the developers.
But as a user I want to have new features and improvements now. And not
with the next stable release. And I want to have them without having to
rework everything I have done so far. (You know, we are like children :-))
I once learned that time to market of a product is crucial for its
success. When you always wait with new features until the next stable
release and then also reserve the right to introduce API
incompatibilities within that same release you are forcing your users to
either use unstable software or drive them away completely to one of
your competitors.
I really urge you to weigh up the effort needed to coordinate a small
bunch of developers against the benefit of being able to release new
features with the guarantee to not introduce API incompatibilities.
5.MAJOR.MINOR.PATCH is my favorite with MAJOR changing when introducing
API incompatiblities and MINOR when adding new features.
Uli
Kevin Menard schrieb:
> While I can appreciate that the kernel devs found the odd/even didn't
> work for them, as a user I appreciated it more.
>
> That's neither here nor there, though. From a pragmatic standpoint,
> the A.B.C.D scheme, aside from being really long, makes POM
> management a pain. If Howard has one idea of what he's going to do
> next and I have another and Ted has a totally different one, we'll
> run into people bumping B, C, or D. At best you end up with a bunch
> of confusing version bumps. At worst, someone forgets to make the
> bump (and this will happen), so 5.B.C+1-SNAPSHOT ends up containing
> an API incompatibility that should have really been in
> 5.B+1-SNAPSHOT. Now, I'll concede that SNAPSHOTs are subject to
> breakage, but they shouldn't be so foolishly.
>
> If these concerns can be allayed using another method, I'm open to
> it. As I've said earlier, it's a non-trivial matter to consider, so
> the more quality suggestions, the better.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Release numbering issues
Posted by Kevin Menard <km...@servprise.com>.
While I can appreciate that the kernel devs found the odd/even didn't work for them, as a user I appreciated it more.
That's neither here nor there, though. From a pragmatic standpoint, the A.B.C.D scheme, aside from being really long, makes POM management a pain. If Howard has one idea of what he's going to do next and I have another and Ted has a totally different one, we'll run into people bumping B, C, or D. At best you end up with a bunch of confusing version bumps. At worst, someone forgets to make the bump (and this will happen), so 5.B.C+1-SNAPSHOT ends up containing an API incompatibility that should have really been in 5.B+1-SNAPSHOT. Now, I'll concede that SNAPSHOTs are subject to breakage, but they shouldn't be so foolishly.
If these concerns can be allayed using another method, I'm open to it. As I've said earlier, it's a non-trivial matter to consider, so the more quality suggestions, the better.
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for your network
www.servprise.com +1 508.892.3823 x308
> -----Original Message-----
> From: Ulrich Stärk [mailto:uli@spielviel.de]
> Sent: Tuesday, February 19, 2008 4:40 PM
> To: Tapestry development
> Subject: Re: Release numbering issues
>
> The even/odd approach has the disadvantage that users might have to
> wait
> for a long time until new features are released in a "stable" release.
> That's why the kernel developers have chosen to abandon this approach.
> I
> personally like the linux kernel versioning scheme:
>
> A.B.C.D
>
> With A being the version number which only changes if there are really
> significant changes like a complete rewrite of Tapestry so this will
> hopefully stay 5 for a long time.
>
> B changes when API changes that are not backwards-compatible are
> introduced
>
> C will change when new features are added and
>
> D changes with bugfixes and is omitted upon release
>
> Upon releasing 5.B.C development efforts would go to 5.B.C+1 and after
> some time 5.B.C+1-rc1 will be released. Release candidates are released
> as long as we think the new release is not stable enought yet. Once it
> has reached a point where it's stable we release 5.B.C+1 and move
> forward to 5.B.C+2
>
> When we have to release a version with bugfixes we add the D part to
> the
> release number. E.g. 5.B.C is released, development is on 5.B.C+1 but
> we
> have to fix a bug in 5.B.C and release it as 5.B.C.1
>
> Uli
>
>
> Robert Zeigler schrieb:
> > +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 <km...@servprise.com>
> 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:hlship@gmail.com]
> >>>> 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: dev-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Howard M. Lewis Ship
> >>
> >> Creator Apache Tapestry and Apache HiveMind
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Release numbering issues
Posted by Ulrich Stärk <ul...@spielviel.de>.
The even/odd approach has the disadvantage that users might have to wait
for a long time until new features are released in a "stable" release.
That's why the kernel developers have chosen to abandon this approach. I
personally like the linux kernel versioning scheme:
A.B.C.D
With A being the version number which only changes if there are really
significant changes like a complete rewrite of Tapestry so this will
hopefully stay 5 for a long time.
B changes when API changes that are not backwards-compatible are introduced
C will change when new features are added and
D changes with bugfixes and is omitted upon release
Upon releasing 5.B.C development efforts would go to 5.B.C+1 and after
some time 5.B.C+1-rc1 will be released. Release candidates are released
as long as we think the new release is not stable enought yet. Once it
has reached a point where it's stable we release 5.B.C+1 and move
forward to 5.B.C+2
When we have to release a version with bugfixes we add the D part to the
release number. E.g. 5.B.C is released, development is on 5.B.C+1 but we
have to fix a bug in 5.B.C and release it as 5.B.C.1
Uli
Robert Zeigler schrieb:
> +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 <km...@servprise.com> 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:hlship@gmail.com]
>>>> 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: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Release numbering issues
Posted by Robert Zeigler <ro...@scazdl.org>.
+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 <km...@servprise.com> 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:hlship@gmail.com]
>>> 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: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Release numbering issues
Posted by Kevin Menard <km...@servprise.com>.
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Release numbering issues
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Feb 19, 2008 12:35 PM, Kevin Menard <km...@servprise.com> 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:hlship@gmail.com]
> > 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Release numbering issues
Posted by Kevin Menard <km...@servprise.com>.
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.
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.
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.
--
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:hlship@gmail.com]
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org