Re: [DISCUSS] Making a release
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?
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?
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;version0.9.6-incubating/version;version0.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;version0.9.6-incubating-SNAPSHOT/
version;version0.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!
RE: [DISCUSS] Making a release
I think that the issue is that the thing that is voted on is the tag.
Additional work might be happening as the vote proceeds; that additional
work may or may not be ready for prime-time.
I expect that over time, we'll be branching earlier anyways and doing
destabilizing work on a branch separate from the release candidate
branch.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
Behalf Of Marc Prud'hommeaux
Sent: Sunday, November 12, 2006 12:53 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [DISCUSS] Making a release
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?
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?
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;version0.9.6-incubating/version;version0.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;version0.9.6-incubating-SNAPSHOT/
version;version0.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
Re: [DISCUSS] Making a release
On Nov 12, 2006, at 1:26 PM, Patrick Linskey wrote:
I think that the issue is that the thing that is voted on is the tag.
Is that actually right? My understanding was that the thing that is
voted on is the artifacts (in this case, the binary and source zip
archives), and that the VCS is not a fundamental part of the release
voting process.
Additional work might be happening as the vote proceeds; that
additional
work may or may not be ready for prime-time.
I expect that over time, we'll be branching earlier anyways and doing
destabilizing work on a branch separate from the release candidate
branch.
True, but my question is whether we should make branches for the sole
purpose of cutting a release or not, which is why I was wondering if
actually saves effort or not.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
Behalf Of Marc Prud'hommeaux
Sent: Sunday, November 12, 2006 12:53 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [DISCUSS] Making a release
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?
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?
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;version0.9.6-incubating/version;version0.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;version0.9.6-incubating-SNAPSHOT/
version;version0.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
RE: [DISCUSS] Making a release
On Nov 12, 2006, at 1:26 PM, Patrick Linskey wrote: I think that the issue is that the thing that is voted on is the tag. Is that actually right? My understanding was that the thing that is voted on is the artifacts (in this case, the binary and source zip archives), and that the VCS is not a fundamental part of the release voting process. I guess I meant the thing that is voted on is what was built from the tag. Assuming that development continues, then if you work from the tag, people only need to consider the differences that have happened on the tag. If we build from the mainline, then people need to consider all changes. Additional work might be happening as the vote proceeds; that additional work may or may not be ready for prime-time. I expect that over time, we'll be branching earlier anyways and doing destabilizing work on a branch separate from the release candidate branch. True, but my question is whether we should make branches for the sole purpose of cutting a release or not, which is why I was wondering if actually saves effort or not. My understanding is that tags and branches are the same thing in svn, so Craig's proposal was that the work of fixing things would happen in the dir created for the tag, and then get merged (or duplicated) into mainline. Consider, for example, my localizer optimization, Abe's nested subquery fixes, and my JDK1.4 switchover. Those all happened after the tag was created. If we include those changes in the thing that we vote on next, then presumably I should take those changes into account (including testing to make sure that the new JDK1.4 stuff really works, etc.) when voting. I'd prefer to just automatically saying +1 since I gave a +1 last time and the changes you made to resolve Eddie's issues are things that I agree with. For the particular issues at hand, I don't think that there is much destabilization, but I do agree that jumping back to current main and re-tagging seems like it's bound to cause problems at some point. It seems like once there's a 0.9.6 tag, we shouldn't be changing the number of the mainline back to 0.9.6, but should instead change things in the tag. Speaking of which, is there a way in svn to freeze a directory, so that once 0.9.6 is approved, we can't mutate that tag / branch / directory? -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [DISCUSS] Making a release
Hi Marc,
I missed Patrick's message. Maybe it's stuck in spam limbo.
On Nov 12, 2006, at 1:32 PM, Marc Prud'hommeaux wrote:
On Nov 12, 2006, at 1:26 PM, Patrick Linskey wrote:
I think that the issue is that the thing that is voted on is the tag.
Is that actually right? My understanding was that the thing that is
voted on is the artifacts (in this case, the binary and source zip
archives), and that the VCS is not a fundamental part of the
release voting process.
The thing that is voted on is the signed artifacts that by definition
are not in svn. The tag is just the way you can reproduce the release
bits without too much effort.
Additional work might be happening as the vote proceeds; that
additional
work may or may not be ready for prime-time.
Right.
I expect that over time, we'll be branching earlier anyways and doing
destabilizing work on a branch separate from the release candidate
branch.
It's difficult to know in advance what the community will require to
take a release branch and clean it up enough to release. People find
bugs; they want to add one more easy but worthwhile feature;
regressions are discovered during testing of other components...
True, but my question is whether we should make branches for the
sole purpose of cutting a release or not, which is why I was
wondering if actually saves effort or not.
If we are willing to freeze the trunk while cutting a release, then
there is no need for a release branch. That includes changing the
poms from SNAPSHOT to normal. And this means no nightly builds while
releasing, which for me is a deal breaker.
Craig
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_
__
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
Behalf Of Marc Prud'hommeaux
Sent: Sunday, November 12, 2006 12:53 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [DISCUSS] Making a release
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?
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?
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;version0.9.6-incubating/version;version0.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;version0.9.6-incubating-SNAPSHOT/
version;version0.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
Re: [DISCUSS] Making a release
On Nov 12, 2006, at 1:46 PM, Patrick Linskey wrote: On Nov 12, 2006, at 1:26 PM, Patrick Linskey wrote: I think that the issue is that the thing that is voted on is the tag. Is that actually right? My understanding was that the thing that is voted on is the artifacts (in this case, the binary and source zip archives), and that the VCS is not a fundamental part of the release voting process. Ahh ... understood. I guess I meant the thing that is voted on is what was built from the tag. Assuming that development continues, then if you work from the tag, people only need to consider the differences that have happened on the tag. If we build from the mainline, then people need to consider all changes. Additional work might be happening as the vote proceeds; that additional work may or may not be ready for prime-time. I expect that over time, we'll be branching earlier anyways and doing destabilizing work on a branch separate from the release candidate branch. True, but my question is whether we should make branches for the sole purpose of cutting a release or not, which is why I was wondering if actually saves effort or not. My understanding is that tags and branches are the same thing in svn, so Craig's proposal was that the work of fixing things would happen in the dir created for the tag, and then get merged (or duplicated) into mainline. Consider, for example, my localizer optimization, Abe's nested subquery fixes, and my JDK1.4 switchover. Those all happened after the tag was created. If we include those changes in the thing that we vote on next, then presumably I should take those changes into account (including testing to make sure that the new JDK1.4 stuff really works, etc.) when voting. I'd prefer to just automatically saying +1 since I gave a +1 last time and the changes you made to resolve Eddie's issues are things that I agree with. For the particular issues at hand, I don't think that there is much destabilization, but I do agree that jumping back to current main and re-tagging seems like it's bound to cause problems at some point. It seems like once there's a 0.9.6 tag, we shouldn't be changing the number of the mainline back to 0.9.6, but should instead change things in the tag. Speaking of which, is there a way in svn to freeze a directory, so that once 0.9.6 is approved, we can't mutate that tag / branch / directory? -Patrick __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: [DISCUSS] Making a release
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;version0.9.6-incubating/version;version0.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;version0.9.6-incubating-SNAPSHOT/
version;version0.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
