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