You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Wendy Smoak <ws...@gmail.com> on 2008/08/29 17:36:22 UTC

Re: Continuum release versioning

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

Re: Continuum release versioning

Posted by 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