Release naming: Tapestry vs. world

["Howard M. Lewis Ship" <hl...@comcast.net>]

Any thoughts on this style of numbering?  I like our conventions, but 
there's something to be said for this approach.

-------- Original Message --------
Subject: 	Re: [RESULT] Regular beta releases
Date: 	Thu, 8 Sep 2005 10:56:10 -0700 (PDT)
From: 	Yoav Shapira <yo...@apache.org>
Reply-To: 	Jakarta Project Management Committee List 
<pm...@jakarta.apache.org>, yoavs@apache.org
To: 	Jakarta Project Management Committee List <pm...@jakarta.apache.org>



Hola,
Just +1 to Martin and Robert's suggestions.  As the release manager for Tomcat
for the past couple of years, I've had to explain our build numbering to
numerous people / organizations.  The vast majority really like it, and I've
seen several organizations adopt it as their own system even for internal
builds.

Yoav

--- Martin Cooper <ma...@apache.org> wrote:

> 
> 
> On Thu, 8 Sep 2005, Howard M. Lewis Ship wrote:
> 
> > "You say tomaytoe I say tomahtoe"
> >
> > To each his own; I find other numbering schemes pretty arcane. I like the 
> > fact that the name delinates its stability (final >= rc > beta > alpha) and
> 
> > there's no confusion about, or lookup needed, to determine this for any 
> > specific release.
> 
> I think you misunderstood. The point of the scheme that Struts uses (which 
> is based on what HTTPD and Tomcat use) is that we don't prejudge quality. 
> We'll first announce a build as, for example, a Struts 1.2.8 Test Build. 
> After the user base has had some time to try it out and report any 
> problems, we'll start a vote to decide on the quality. The outcome of the 
> vote could be Beta, Final, or scratch the build. Even if 1.2.8 turns out 
> to be Beta, 1.2.9 starts out as a Test Build, since we might have screwed 
> something up, and it might be worse than 1.2.8. (Obviously, we hope not, 
> but the key is not to _assume_ that it's Beta quality just because 1.2.8 
> was.)
> 
> --
> Martin Cooper
> 
> 
> > robert burrell donkin wrote:
> >
> >> On Wed, 2005-09-07 at 18:27 -0400, Howard Lewis Ship wrote:
> >> 
> >>> As per the ongoing discussion, this is a vote to introduce a new
> >>> procedure: regular weekly beta releases until Tapestry 4.0 is ready
> >>> for release. 
> >> 
> >> please consider using a different name for these builds. IMHO a more
> >> conventional name would be 'milestone build'. 
> >> httpd (and a number of other popular and important projects IIRC
> >> including tomcat and struts) now use a release system whereby the same
> >> release is promoted from candidate to beta to alpha to full release.
> >> this system seems to work very well for projects with large users bases
> >> and helps to ensure that full releases are of top quality. 
> >> even if tapestry does not feel that they are ready for a move to such a
> >> system, i'd recommend choosing a name for the proposed builds that
> >> allows an easy move to release system of that kind. 
> >> - robert
> >> 
> >> 
> >
> > -- 
> > Howard M. Lewis Ship
> > Independent J2EE / Open-Source Java Consultant
> > Creator, Jakarta Tapestry
> > Creator, Jakarta HiveMind
> >
> > Professional Tapestry training, mentoring, support
> > and project work.  http://howardlewisship.com
> >
> >
> 




-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: Release naming: Tapestry vs. world

[Jesse Kuhnert <jk...@gmail.com>]

I think the versioning convention being used by projects like tomcat works 
well for commercial applications, but doesn't really fit open source models 
very well.

The fact that their website has all kinds of little disclaimers and 
"gotcha"s explaining the stability of one version or another seems to 
support this fact. 

In the commcercial world (being very very general here) releases are 
typically made quarterly, sometimes sooner or later, but generally speaking 
that seems to be the model. These releases are also expected to be more or 
less functioning without any bugs. Users have gotten used to the idea (some 
at least) that you should be very wary of any version of software with a .0 
numeral after it. They, just like tomcat, either have to document the fact 
that some things are beta-ish or buggy , or don't advertise this fact at all 
and just queitly fix the bugs for the next .X release. This seems flawed in 
the commercial world as well.

I think the convention being used by tapestry/hivemind/hibernate/etc. is a 
much more honest, and well documented approach. Anyone who doesn't know what 
"alpha" means should hopefully be scared enough by the name to stear very 
clear of it. Things with a name of beta would typically infer that the 
software state is pretty much done, with at worst a known set of bugs and 
possibly a tiny feature here or there, and at best a product that everyone 
thinks is working well and just needs people to use it to flush out any 
remaining bugs/issues that may be creeping around.

A hybrid of the eclipse model combined with tapestry's existing naming 
scheme would be the most ideal situation in my eyes. Milestone names and 
feature goals (like any typical project) would coincide with the release 
name, as well as state of release (ie alpha-1,beta-48 ;) etc..). 

For obvious software project management reasons, Milestone goals have been 
proven a very effective solution for developers/development, and it would 
probably help immensely with users and their expectations of each release. 
Eclipse having a milestone plan page for the milestones would also be 
helpful (don't know if I've ever seen one...maybe) . Perhaps it is something 
only the dev's use internally, but in the interest of honesty, as well as 
open communication with users it would be nice to see made very public and 
obvious. 

Wtf would that even look like? tapestry-4-beta-1-m5? Something less 
confusing maybe, but it seems workable. 

my 2 cents 

jesse

Re: Release naming: Tapestry vs. world

[Harish Krishnaswamy <ha...@gmail.com>]

In an agile development process, I don't really see a difference between 
alpha and beta. I actually like the eclipse versioning system where every 
release is a migration and finally may be we can have one or more betas 
before the final release. But I do agree with the point that the quality is 
determined after the fact a release has been made.

-Harish

On 9/8/05, Howard M. Lewis Ship <hl...@comcast.net> wrote:
> 
> Any thoughts on this style of numbering? I like our conventions, but
> there's something to be said for this approach.
> 
> -------- Original Message --------
> Subject: Re: [RESULT] Regular beta releases
> Date: Thu, 8 Sep 2005 10:56:10 -0700 (PDT)
> From: Yoav Shapira <yo...@apache.org>
> Reply-To: Jakarta Project Management Committee List
> <pm...@jakarta.apache.org>, yoavs@apache.org
> To: Jakarta Project Management Committee List <pm...@jakarta.apache.org>
> 
> 
> 
> Hola,
> Just +1 to Martin and Robert's suggestions. As the release manager for 
> Tomcat
> for the past couple of years, I've had to explain our build numbering to
> numerous people / organizations. The vast majority really like it, and 
> I've
> seen several organizations adopt it as their own system even for internal
> builds.
> 
> Yoav
> 
> --- Martin Cooper <ma...@apache.org> wrote:
> 
> >
> >
> > On Thu, 8 Sep 2005, Howard M. Lewis Ship wrote:
> >
> > > "You say tomaytoe I say tomahtoe"
> > >
> > > To each his own; I find other numbering schemes pretty arcane. I like 
> the
> > > fact that the name delinates its stability (final >= rc > beta > 
> alpha) and
> >
> > > there's no confusion about, or lookup needed, to determine this for 
> any
> > > specific release.
> >
> > I think you misunderstood. The point of the scheme that Struts uses 
> (which
> > is based on what HTTPD and Tomcat use) is that we don't prejudge 
> quality.
> > We'll first announce a build as, for example, a Struts 1.2.8 Test Build.
> > After the user base has had some time to try it out and report any
> > problems, we'll start a vote to decide on the quality. The outcome of 
> the
> > vote could be Beta, Final, or scratch the build. Even if 1.2.8 turns out
> > to be Beta, 1.2.9 starts out as a Test Build, since we might have 
> screwed
> > something up, and it might be worse than 1.2.8. (Obviously, we hope not,
> > but the key is not to _assume_ that it's Beta quality just because 1.2.8
> > was.)
> >
> > --
> > Martin Cooper
> >
> >
> > > robert burrell donkin wrote:
> > >
> > >> On Wed, 2005-09-07 at 18:27 -0400, Howard Lewis Ship wrote:
> > >>
> > >>> As per the ongoing discussion, this is a vote to introduce a new
> > >>> procedure: regular weekly beta releases until Tapestry 4.0 is ready
> > >>> for release.
> > >>
> > >> please consider using a different name for these builds. IMHO a more
> > >> conventional name would be 'milestone build'.
> > >> httpd (and a number of other popular and important projects IIRC
> > >> including tomcat and struts) now use a release system whereby the 
> same
> > >> release is promoted from candidate to beta to alpha to full release.
> > >> this system seems to work very well for projects with large users 
> bases
> > >> and helps to ensure that full releases are of top quality.
> > >> even if tapestry does not feel that they are ready for a move to such 
> a
> > >> system, i'd recommend choosing a name for the proposed builds that
> > >> allows an easy move to release system of that kind.
> > >> - robert
> > >>
> > >>
> > >
> > > --
> > > Howard M. Lewis Ship
> > > Independent J2EE / Open-Source Java Consultant
> > > Creator, Jakarta Tapestry
> > > Creator, Jakarta HiveMind
> > >
> > > Professional Tapestry training, mentoring, support
> > > and project work. http://howardlewisship.com
> > >
> > >
> >
> 
> 
> 
> 
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
> 
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
>

Re: Release naming: Tapestry vs. world

[Kevin Menard <km...@servprise.com>]

Howard M. Lewis Ship wrote:
> Any thoughts on this style of numbering?  I like our conventions, but
> there's something to be said for this approach.

Not being a dev, I'd take what I'm about to say with a grain of salt.

I like the idea of voting on releases in general, but I think we've all
seen how it has hindered the release of betas.  I think what Tapestry
just did with the recent vote for weekly betas was unprecedented.
Anyway, my point is, voting to release and then voting again to
determine the status of that release just seems like it would tie things
up even more.  I'd be fine with that if I could see something gained
from it, but I'm not sure there is.  Everyone has a general feeling of
where the project is at.  We're in beta, so voting for every release to
confirm it's a beta seems like a waste to me.

So, I'm +1 with the current naming convention.  However, RC never really
sat well with me, or at least the way people use it.  For example, the
Eclipse folks plan 3 - 5 RCs before an actual release.  If additional
RCs are *planned*, then the first one really wasn't a candidate for
release.  I certainly realize it asserts that it's a step above beta in
terms of quality, but it's not really a release candidate.  So, whenever
 Tapestry hits the RC stage, I really hope the releases are candidates
for releases and not just a beta by another name.

-- 
Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org