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 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.
hmmm .... now I'm confused. What is server/tags/geronimo-parent and why
would it replace server/tags/2.2?
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.
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] http://cwiki.apache.org/GMOxPMGT/geronimo-release-process.html
Joe
