Continuum release versioning

[Wendy Smoak <ws...@gmail.com>]

We've been discussing how to version releases over at Archiva, and
seem to have settled on milestones -> final -> patch releases.  No
more -alpha and -beta designations in the filename.

Brett summarized the options and gave his opinions:

> - Maven style (alpha, beta, final, point release)
> - Eclipse style (M1, M2, M3, final, point release - though Eclipse don't have the last ones)  [Spring style then? -ws]
> - httpd style (.0.0, .0.1, .0.2, .0.3)

> And here are [Brett's] opinions:
> - I'm tired of the Maven style. I've heard people actually saying it's ok to break things because it's just an alpha. I would rather encourage development practices that mean every release should be production quality.
> - But I'm a realist - releases need broader testing to assess production quality.
> - milestones seem more akin to a set roadmap per release that gets done in stages, rather than timeboxing
> - httpd-style can be a little confusing to users, at least at first (will the real release please stand up?). I think this is mitigated by only putting the final final releases on release repo and mirrors
> - httpd-style is not very effective for "milestones", since you end up making the 20th or 30th release your first "real" release
> - Hudson uses the extreme of the last style (everything is a feature release, everything is a final release)

My preference is httpd-style, where it's just a number and you apply a
quality designation afterwards.  But I can live with milestones. :)  I
_don't_ like baking the quality into the version number.

Any thoughts on this for Continuum, before we simply go on using the
strategy we inherited from Maven?

-- 
Wendy

Re: Continuum release versioning

[Wendy Smoak <ws...@gmail.com>]

On Sun, May 11, 2008 at 2:04 PM, Olivier Lamy <ol...@apache.org> wrote:
> Hi,
> I prefer the httpd style too (but no real issue with the maven one).
> A release is a release. IHMO we don't need to use some "marketing" names
> :-).

It seems that we need to revisit this topic. :)

IMO if we're going to release early and (fairly) often, we need a way
to communicate quality/stability to users.

My preference is to do 1.3.0, 1.3.1, 1.3.2 and to "label" them
(alpha/beta/milestone/GA) in the release announcement and download
page.  This means that 1.3.0 doesn't have to be feature complete, and
that we may skip versions if a problem is found and a vote doesn't
pass.

Another option is the way Archiva has decided to do it, with
milestones 1.3-M1, 1.3-M2, 1.3 then 1.3.1, 1.3.2 patch releases.  Here
we need to avoid reusing version numbers, so we might need a release
candidate process in order to make sure "1.3" doesn't get built over
and over.

Are there any modifications to the above, or other versioning schemes
we should consider?

Thanks,
-- 
Wendy

Re: Continuum release versioning

[Brett Porter <br...@apache.org>]

I never shared my actual preference :)

I'm happy with either milestones or httpd-style. I'm starting to get a  
leaning towards the latter.

- Brett

On 12/05/2008, at 6:04 AM, Olivier Lamy wrote:

> Hi,
> I prefer the httpd style too (but no real issue with the maven one).
> A release is a release. IHMO we don't need to use some "marketing"  
> names
> :-).
>
> --
> Olivier
>
> 2008/5/11 Wendy Smoak <ws...@gmail.com>:
>
>> We've been discussing how to version releases over at Archiva, and
>> seem to have settled on milestones -> final -> patch releases.  No
>> more -alpha and -beta designations in the filename.
>>
>> Brett summarized the options and gave his opinions:
>>
>>> - Maven style (alpha, beta, final, point release)
>>> - Eclipse style (M1, M2, M3, final, point release - though Eclipse  
>>> don't
>> have the last ones)  [Spring style then? -ws]
>>> - httpd style (.0.0, .0.1, .0.2, .0.3)
>>
>>> And here are [Brett's] opinions:
>>> - I'm tired of the Maven style. I've heard people actually saying  
>>> it's ok
>> to break things because it's just an alpha. I would rather encourage
>> development practices that mean every release should be production  
>> quality.
>>> - But I'm a realist - releases need broader testing to assess  
>>> production
>> quality.
>>> - milestones seem more akin to a set roadmap per release that gets  
>>> done
>> in stages, rather than timeboxing
>>> - httpd-style can be a little confusing to users, at least at  
>>> first (will
>> the real release please stand up?). I think this is mitigated by only
>> putting the final final releases on release repo and mirrors
>>> - httpd-style is not very effective for "milestones", since you  
>>> end up
>> making the 20th or 30th release your first "real" release
>>> - Hudson uses the extreme of the last style (everything is a feature
>> release, everything is a final release)
>>
>> My preference is httpd-style, where it's just a number and you  
>> apply a
>> quality designation afterwards.  But I can live with  
>> milestones. :)  I
>> _don't_ like baking the quality into the version number.
>>
>> Any thoughts on this for Continuum, before we simply go on using the
>> strategy we inherited from Maven?
>>
>> --
>> Wendy
>>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/

Re: Continuum release versioning

[Olivier Lamy <ol...@apache.org>]

Hi,
I prefer the httpd style too (but no real issue with the maven one).
A release is a release. IHMO we don't need to use some "marketing" names
:-).

--
Olivier

2008/5/11 Wendy Smoak <ws...@gmail.com>:

> We've been discussing how to version releases over at Archiva, and
> seem to have settled on milestones -> final -> patch releases.  No
> more -alpha and -beta designations in the filename.
>
> Brett summarized the options and gave his opinions:
>
> > - Maven style (alpha, beta, final, point release)
> > - Eclipse style (M1, M2, M3, final, point release - though Eclipse don't
> have the last ones)  [Spring style then? -ws]
> > - httpd style (.0.0, .0.1, .0.2, .0.3)
>
> > And here are [Brett's] opinions:
> > - I'm tired of the Maven style. I've heard people actually saying it's ok
> to break things because it's just an alpha. I would rather encourage
> development practices that mean every release should be production quality.
> > - But I'm a realist - releases need broader testing to assess production
> quality.
> > - milestones seem more akin to a set roadmap per release that gets done
> in stages, rather than timeboxing
> > - httpd-style can be a little confusing to users, at least at first (will
> the real release please stand up?). I think this is mitigated by only
> putting the final final releases on release repo and mirrors
> > - httpd-style is not very effective for "milestones", since you end up
> making the 20th or 30th release your first "real" release
> > - Hudson uses the extreme of the last style (everything is a feature
> release, everything is a final release)
>
> My preference is httpd-style, where it's just a number and you apply a
> quality designation afterwards.  But I can live with milestones. :)  I
> _don't_ like baking the quality into the version number.
>
> Any thoughts on this for Continuum, before we simply go on using the
> strategy we inherited from Maven?
>
> --
> Wendy
>

Re: Continuum release versioning

[Rahul Thakur <ra...@gmail.com>]

I am not sure why we need to change release versioning and I don't see a 
difference how Eclipse milestones releases differ from beta(s) or RC(s) 
that we have for Maven. Eclipse milestones do not freeze APIs until 
later stages.

If we want to put production quality releases out there, we have the 
option of planning and releasing 'Release Candidates' more oft, such 
that they get used/tested by community.

Rahul



Wendy Smoak wrote:
> We've been discussing how to version releases over at Archiva, and
> seem to have settled on milestones ->  final ->  patch releases.  No
> more -alpha and -beta designations in the filename.
>
> Brett summarized the options and gave his opinions:
>
>> - Maven style (alpha, beta, final, point release)
>> - Eclipse style (M1, M2, M3, final, point release - though Eclipse don't have the last ones)  [Spring style then? -ws]
>> - httpd style (.0.0, .0.1, .0.2, .0.3)
>
>> And here are [Brett's] opinions:
>> - I'm tired of the Maven style. I've heard people actually saying it's ok to break things because it's just an alpha. I would rather encourage development practices that mean every release should be production quality.
>> - But I'm a realist - releases need broader testing to assess production quality.
>> - milestones seem more akin to a set roadmap per release that gets done in stages, rather than timeboxing
>> - httpd-style can be a little confusing to users, at least at first (will the real release please stand up?). I think this is mitigated by only putting the final final releases on release repo and mirrors
>> - httpd-style is not very effective for "milestones", since you end up making the 20th or 30th release your first "real" release
>> - Hudson uses the extreme of the last style (everything is a feature release, everything is a final release)
>
> My preference is httpd-style, where it's just a number and you apply a
> quality designation afterwards.  But I can live with milestones. :)  I
> _don't_ like baking the quality into the version number.
>
> Any thoughts on this for Continuum, before we simply go on using the
> strategy we inherited from Maven?
>

Re: Continuum release versioning

[Wendy Smoak <ws...@gmail.com>]

On Fri, Aug 29, 2008 at 8:36 AM, Wendy Smoak <ws...@gmail.com> wrote:

> Then I'm going to prepare Continuum 1.2.0.

Olivier volunteered for this. :)  We had a brief discussion on irc
about 1.2 vs 1.2.0 ... either works for me.

I did want to write a bit more about this style of release versioning
(or just paste what I wrote on irc) to see if there are any thoughts
or comments.

With http-style versioning, you end up with tags like this...
http://svn.apache.org/repos/asf/httpd/httpd/tags/ (or my preference is
to keep all of them, even if it doesn't go public, like this
http://svn.apache.org/repos/asf/struts/struts2/tags/ .)

When we vote, we can decide what label to put on it... milestone,
alpha, beta, GA ... or none, and it doesn't go in the filename.  If
the vote doesn't pass, we move on to the next one-- it's okay to skip
numbers.

So if we release 1.2.0 as beta, and then decide that there's nothing
wrong with it, we can promote it to GA without going through another
release process.  We simply vote again, and change the text on the
download web page.

If we don't attach a label to it in the announcement/on the download
page, people will assume it's GA, ready for production use.

The first one in the series doesn't have to be feature complete.  If
we decide it's a milestone or an alpha, we can still make changes in a
dot release after that.

It all comes down to... it's just a version number, and it means
exactly what we say it means, no more, no less.

-- 
Wendy

Re: Continuum release versioning

[Wendy Smoak <ws...@gmail.com>]

Okay, I'm going with httpd- (tomcat-, struts-) style versioning for 1.2.

Specifically, I'm going to branch "continuum-1.2.x" just prior to
Emmanuel's changes for CONTINUUM-1858 which require a new version of
Redback.

If I find anything else problematic for a release, I may go back and
branch from an earlier revision.

Then I'm going to prepare Continuum 1.2.0.  I don't expect that this
one will pass.  I may not even call a vote.  There will likely be some
things to work out in the build process, and IMO the docs need work.

Then onward to 1.2.1, 1.2.2, etc.  Anything appropriate for 1.2 can be
merged back from trunk.  Nothing that would block an immediate release
should be merged.

Trunk will move on to 1.3 or 2.0 depending on a separate discussion.
For the moment, 1.2-SNAPSHOT on trunk will not conflict with
1.2.0-SNAPSHOT on the branch, so no rush there.

Any comments?

-- 
Wendy