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 Tue, 13 May 2008 03:05:12 GMT
David Jencks wrote:
> On May 12, 2008, at 11:54 AM, Joe Bohn wrote:
>> 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.
> Wouldn't we end up with server/branches/2.2 and 
> server/tags/geronimo-parent-2.2?  These seem sufficiently distinct to me 
> to avoid confusion.

hmmm .... now I'm confused.  What is server/tags/geronimo-parent and why 
would it replace server/tags/2.2?

Actually, since this is really a discussion about samples, how would we 
not end up with samples/branches/2.1 and samples/tags/2.1 (where the 
branches continually used for 2.1.x releases and tags is the 2.1 
release) if there is not a way to specify the artifact release version 
independently from the tag release version?  What am I missing?

I suspect the naming issue is why we named the tag sever/tags/2.1.0 when 
we released Geronimo 2.1 so that the tag would have a different version 
number from the branch that was to continue, server/branches/2.1.


> thanks
> david jencks
>>> 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