Assuming that all the release issues apply to the trunk as well,
which is not necessarily everything. The issue is that if you don't
branch, until you have a release, the trunk is stuck at the release
level which means you can't have nightly builds of SNAPSHOT or do
any future development on trunk. And my experience is that it takes
a minimum of a week or two from the time you want to do a release
to the time the release is ready to be tagged.
That makes sense. And it's probably wiser than my "cross my fingers
and go" approach.
On Nov 12, 2006, at 1:45 PM, Craig L Russell wrote:
Hi Marc,
On Nov 12, 2006, at 12:53 PM, Marc Prud'hommeaux wrote:
Craig-
The only difference is that we initially branch from the trunk and
perform the updates to the pom.xml files there, and then release
against the branch, correct?
Yes.
I don't necessarily object to releasing off of a branch, but does
it really save any effort? After all, if release candidate
problems exist (as they have the last couple times I tried to
create a release), then so therefore commit changes to the branch,
we'll still need to perform the additional step of merging the
changes in the branch back into the trunk, right?
Assuming that all the release issues apply to the trunk as well,
which is not necessarily everything. The issue is that if you don't
branch, until you have a release, the trunk is stuck at the release
level which means you can't have nightly builds of SNAPSHOT or do
any future development on trunk. And my experience is that it takes
a minimum of a week or two from the time you want to do a release
to the time the release is ready to be tagged.
Craig
On Nov 12, 2006, at 10:40 AM, Craig L Russell wrote:
I'd like to propose something like this (edited the wiki page)
The main difference is that upon starting the release process, we
create a branch in which to resolve the release issues while
maintaining the trunk for further development.
h2. Tasks that need to be performed for each release
{info}In the examples below, it is assumed that the current
committed version of OpenJPA is *0.9.6-incubating-SNAPSHOT*, and
the version of the official release will be *0.9.6-incubating*{info}
# Make sure the [#One time setup] steps have been performed
# Create a branch from the trunk (or from a previous branch if
maintaining a branch)
{code:none}
svn copy -m "Create branch for OpenJPA Release 0.9.6-incubating"
https://svn.apache.org/repos/asf/incubator/openjpa/trunk
https://svn.apache.org/repos/asf/incubator/openjpa/releases/
0.9.6-incubating
{code}
# Change to the trunk for the next steps
# Update the pom.xml files to the subsequent version with the -
SNAPSHOT suffix:
{code:none}
perl -pi -e "s;<version>0.9.6-incubating</version>;<version>0.9.7-
incubating-SNAPSHOT</version>;g" pom.xml */pom.xml
{code}
# Commit the POM changes in the trunk
{code:none}
svn commit -m "Updated to version 0.9.7-incubating-SNAPSHOT"
{code}
# Change to the branch for the new release for the following steps
# Update the POMs to remove "-SNAPSHOT" from the version. If you
have perl installed, you can easily do it with a single command:
{code:none}
perl -pi -e 's;<version>0.9.6-incubating-SNAPSHOT</
version>;<version>0.9.6-incubating</version>;g' pom.xml */pom.xml
{code}
# Commit the POM changes
{code:none}
svn commit -m "Updated to version 0.9.6-incubating"
{code}
# Perform the build with documentation and install it in the
local repository (this step is required because there is a bug in
Maven's javadoc generation aggregated between multiple modules):
{code:none}
mvn clean install -Pdocbook-profile,sign-release
{code}
{note}This operation will also sign the release artifacts with
the *gpg* utility using the <username>@apache.org key. If your
code signing key is under a different address, specify it by
appending the following argument to the command above: -
[EMAIL PROTECTED]
# Verify the signatures:
{code:none}
gpg --multifile --verify openjpa-project/target/assembly/*.asc
{code}
# Build the javadocs and perform the deploy upload:
{code:none}
mvn verify deploy -Pjavadoc-profile,sign-release
{code}
# Start a vote for the release on the [mailto:open-jpa-
[EMAIL PROTECTED] mailing list. For an example of the
mail, see [this archived vote|http://mail-archives.apache.org/
mod_mbox/incubator-open-jpa-dev/200611.mbox/%3c07C7A237-DE80-4BC5-
[EMAIL PROTECTED]
# If the vote is successful after 3 days, mail
[mailto:[EMAIL PROTECTED] starting a vote for
authorization to release
# Once that vote is successful, update the [http://
cwiki.apache.org/openjpa/downloads.html] page with information
about the download
# Tag the view with the release number:
{code:none}
svn copy -m "OpenJPA Release 0.9.6-incubating"
https://svn.apache.org/repos/asf/incubator/openjpa/releases/
0.9.6-incubating
https://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6-
incubating
{code}
# The branch can now be used to apply patches for future releases
using the branch as a basis (e.g. to create 0.9.6.1-incubating).
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/
products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
