Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=C7rIaSqmfdLS4nlFr2zVT82c0FX5KVlQ81Ow/5UD0gW8L6oYOId6YhKPjcECf85o;
  h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <48288CD1.8030403@earthlink.net>
Date: Mon, 12 May 2008 14:30:41 -0400
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Release process questions
References: <482869A3.8020608@earthlink.net>
 <68105A53-4DD8-4E23-A6C4-01CB1ACA418C@yahoo.com>
In-Reply-To: <68105A53-4DD8-4E23-A6C4-01CB1ACA418C@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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