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
