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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
