geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Release process questions
Date Tue, 13 May 2008 16:02:03 GMT

On May 12, 2008, at 8:05 PM, Joe Bohn wrote:

> 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
>>>>> 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?

The release plugin generates tags named like <project-name>-<release- 
version>.  I might have the geronimo-parent name wrong.
> 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.

I suspect that it  was due to the process used instead of the release  
plugin, which IIUC involved making a release branch and then moving it  
to tags.  Such a branch needs a different name than what it is copied  
from.  If we were to use the release plugin this would be unnecessary.

david jencks

> Joe
>> 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] 
>>>>>> process.html
>>>>>> Joe

View raw message