geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Release process questions
Date Mon, 12 May 2008 20:03:42 GMT

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.

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] http://cwiki.apache.org/GMOxPMGT/geronimo-release-process.html
>>>>
>>>>
>>>> Joe
>>>>
>>>
>>>
>


Mime
View raw message