geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Release process questions
Date Mon, 12 May 2008 18:54:56 GMT
Joe Bohn wrote:
> David Jencks wrote:
>> I may not be understanding the issues here..... if so please point 
>> this out.
>> On May 12, 2008, at 9:00 AM, Joe Bohn wrote:
>>> The new release process [1] generally assumes that we are releasing 
>>> from  trunk and always bumps the version number up by one.
>> Those are not intended to be assumptions :-)  Maybe bad writing.
> Ah ... ok.  The wiki mentioned that we should avoid the complexity of 
> releasing from branches in favor of releasing from trunk.  I took this 
> too literally.  IIUC the intent is that we should not be creating a 
> temporary branch just to later convert it to a tag for a release.
>>> However, for things like samples we want to keep version numbers 
>>> consistent with the Geronimo Server versions and as such we would 
>>> need to release from branches.  So here are some questions:
>>> #1 Can we follow the new release process from a branch 
>>> (geronimo/samples/branches/2.1) rather than trunk?  I think this 
>>> should work.  Anybody know of any issues?
>> I'm pretty sure this should work fine, I did something very similar 
>> with activemq 4.1.2
> Ok, I'll give that a shot.
>>> #2 Releasing from branches/2.1 would result in the versions in the 
>>> branch being updated to 2.2-SNAPSHOT and a tag/2.1 release (I think). 
>>> However, we want the branch to live on as a 2.1.* branch ... so I 
>>> assume that I could just manually update the versions to 
>>> 2.1.1-SNAPSHOT from 2.2-SNAPSHOT.  Likewise, I would rename the tag 
>>> from tags/2.1 to tags/2.1.0.  Does anybody see a problem with this 
>>> (see #3 for another idea)?  After the initial jump from the 2 digit 
>>> version to the 3 digit version things should work normally for future 
>>> releases.
>> I like what activemq does more and more.  With numbers transposed to 
>> match our versions, they keep the branch in branches/2.1, the branch 
>> version at 2.1-SNAPSHOT, and release 2.1.1, 2.1.2, 2.1.3, ... from 
>> this branch.  You just need to fill in the 2.1.x release version and 
>> 2.1-SNAPSHOT branch version when you run mvn release:prepare.  Even if 
>> we dont keep the version at 2.1-SNAPSHOT but update it to 
>> 2.1.(x+1)-SNAPSHOT I think the branch name in svn should continue to 
>> be branches/2.1
> This is the same process that we followed with 2.1.  I'll dig into the 
> details of specifying the releases rather than allowing the defaults 
> that bump up the version number of the release by 1.
>>> #3 The previous question makes me wonder if we should be following 
>>> consistent 2 or 3 digit version numbers for projects which should 
>>> eliminate the need for the renames.  Should Geronimo 2.1 (and hence 
>>> Geronimo Samples for 2.1) have been versioned 2.1.0 rather than 2.1.  
>>> It seems that is the version number we adopted for the server tag 
>>> which is called tags/2.1.0.  It would make it possible to use the 
>>> maven-release plugin for major versions as well as minor versions.  
>>> The branch would still be branches/2.1 but the version for the poms 
>>> would be 2.1.x-SNAPSHOT as we currently do for server branches/2.1.  
>>> Thoughts? If we adopted this strategy we would also want to revision 
>>> server trunk from 2.2-SNAPSHOT to 2.2.0-SNAPSHOT.
>> I think anything we do that isn't from the release plugin should be 
>> ignored as guidance.  I think the release plugin creates tags like 
>> <project-name>-<release-version> under tags.  This is fine IMNSHO.

Actually, I did think of one addition concern with our current numbering 
and using the maven release plugin.  If we only use 2 digit version 
numbers for major releases then we would end up with tags/2.2 and 
branches/2.2.   This may be a point of confusion when looking at our svn 
repos (and I suspect the reason that we have tags/2.1.0 rather than 
tags/2.1 right now).  NOTE:  I have not yet looked into the how the 
version is specified with the maven-release-plugin.  Perhaps we can 
specify the release version and the tag version independently in which 
case I could name the appropriately via the plugin.

> I wasn't proposing anything that wasn't included in the release plugin 
> with #3 (I was actually proposing that with #2 ... but specifying the 
> releases should eliminate the need for that).  The only advantage to 
> doing 3 digit versions consistently would be that we could use the 
> defaults from the release plugin rather than having to specify the 
> versions.
>> At the moment I'd prefer that our releases be numbered 2.2, 2.2.1, 
>> 2.2.2,... rather than 2.2.0, 2.2.1, ...  I don't understand what 
>> renames you are proposing or why they would be needed.
>> I wonder if we could remove the old release instructions from the wiki?
> I think we should keep the old instructions for a little while longer 
> (esp. for releasing the Geronimo Server).  I added a third section that 
> highlights the steps I did as a mixture of the new and the old process 
> .. but I think it still alludes to the old process at the moment.  I'll 
> try to get that updated more clearly and remove the old process when it 
> is complete.
>> thanks
>> david jencks
>>> [1]
>>> Joe

View raw message