Author: dklco
Date: Mon Jul 8 14:17:10 2013
New Revision: 1500747
URL: http://svn.apache.org/r1500747
Log:
Cleaning up the list formatting and a type-o
Modified:
sling/site/trunk/content/documentation/development/release-management.mdtext
Modified:
sling/site/trunk/content/documentation/development/release-management.mdtext
URL:
http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/development/release-management.mdtext?rev=1500747&r1=1500746&r2=1500747&view=diff
==============================================================================
---
sling/site/trunk/content/documentation/development/release-management.mdtext
(original)
+++
sling/site/trunk/content/documentation/development/release-management.mdtext
Mon Jul 8 14:17:10 2013
@@ -53,49 +53,31 @@ First prepare your POMs for release:
1. Make sure there are no snapshots in the POMs to be released
1. Check that your POMs will not lose content when they are rewritten during
the release process
-
- $ mvn release:prepare -DdryRun=true
-
-Compare the original `pom.xml` with the one called `pom.xml.tag` to see if the
license or any other info has been removed. This has been known to happen if
the starting `<project>` tag is not on a single line. The only things that
should be different between these files are the `<version>` and `<scm>`
elements. If there are any other changes, you must fix the original `pom.xml`
file and commit before proceeding with the release.
+ $ mvn release:prepare -DdryRun=true
+ Compare the original `pom.xml` with the one called `pom.xml.tag` to see if
the license or any other info has been removed. This has been known to happen
if the starting `<project>` tag is not on a single line. The only things that
should be different between these files are the `<version>` and `<scm>`
elements. If there are any other changes, you must fix the original `pom.xml`
file and commit before proceeding with the release.
1. Publish a snapshot
-
- $ mvn deploy
- ...
- [INFO] [deploy:deploy]
- [INFO] Retrieving previous build number from apache.snapshots.https
- ...
-
-If you experience an error during deployment like a HTTP 401 check your
settings for the required server entries as outlined in the *Prerequisites*
-
-Make sure the generated artifacts respect the Apache release
[rules](http://www.apache.org/dev/release.html): NOTICE and LICENSE files
should be present in the META-INF directory within the jar. For \-sources
artifacts, be sure that your POM does not use the maven-source-plugin:2.0.3
which is broken. The recommended version at this time is 2.0.4
-
-You should verify the deployment under the
[snapshot](https://repository.apache.org/content/groups/snapshots/org/apache/sling)
repository on Apache
-
-### Prepare the release
-
- $ mvn release:clean
- $ mvn release:prepare
-
- Preparing the release will create the new tag in SVN, automatically checking
in on your behalf
-
-If you get a build failure because of an SVN commit problem (namely *The
specified baseline is not the latest baseline, so it may not be checked out.*),
just repeat the `mvn release:prepare` command until SVN is happy. This is based
on a known timing issue when using the European SVN mirror.
-
-### Stage the release for a vote
-
- $ mvn release:perform
-
-The release will automatically be inserted into a temporary staging repository
for you, see the Nexus [staging
documentation](http://www.sonatype.com/books/nexus-book/reference/staging.html)
for full details
-
-You can continue to use `mvn release:prepare` and `mvn release:perform` on
other sub-projects as necessary on the same machine and they will be combined
in the same staging repository - this is useful when making a release of
multiple Sling modules.
-
-Then, close the staging repository:
-
- * Login to [https://repository.apache.org](https://repository.apache.org)
using your Apache SVN credentials. Click on *Staging* on the left. Then click
on *org.apache.sling* in the list of repositories. In the panel below you
should see an open repository that is linked to your username and IP. Right
click on this repository and select *Close*. This will close the repository
from future deployments and make it available for others to view. If you are
staging multiple releases together, skip this step until you have staged
everything
-
- * Verify the staged artifacts
+ $ mvn deploy
+ ...
+ [INFO] [deploy:deploy]
+ [INFO] Retrieving previous build number from apache.snapshots.https
+ ...
+ * If you experience an error during deployment like a HTTP 401 check your
settings for the required server entries as outlined in the *Prerequisites*
+ * Make sure the generated artifacts respect the Apache release
[rules](http://www.apache.org/dev/release.html): NOTICE and LICENSE files
should be present in the META-INF directory within the jar. For \-sources
artifacts, be sure that your POM does not use the maven-source-plugin:2.0.3
which is broken. The recommended version at this time is 2.0.4
+ * You should verify the deployment under the
[snapshot](https://repository.apache.org/content/groups/snapshots/org/apache/sling)
repository on Apache
+1. Prepare the release
+ $ mvn release:clean
+ $ mvn release:prepare
+ * Preparing the release will create the new tag in SVN, automatically
checking in on your behalf
+ * If you get a build failure because of an SVN commit problem (namely *The
specified baseline is not the latest baseline, so it may not be checked out.*),
just repeat the `mvn release:prepare` command until SVN is happy. This is based
on a known timing issue when using the European SVN mirror.
+1. Stage the release for a vote
+ $ mvn release:perform
+ * The release will automatically be inserted into a temporary staging
repository for you, see the Nexus [staging
documentation](http://www.sonatype.com/books/nexus-book/reference/staging.html)
for full details
+ * You can continue to use `mvn release:prepare` and `mvn release:perform`
on other sub-projects as necessary on the same machine and they will be
combined in the same staging repository - this is useful when making a release
of multiple Sling modules.
+1. Close the staging repository:
+ * Login to [https://repository.apache.org](https://repository.apache.org)
using your Apache SVN credentials. Click on *Staging* on the left. Then click
on *org.apache.sling* in the list of repositories. In the panel below you
should see an open repository that is linked to your username and IP. Right
click on this repository and select *Close*. This will close the repository
from future deployments and make it available for others to view. If you are
staging multiple releases together, skip this step until you have staged
everything
+1. Verify the staged artifacts
* If you click on your repository, a tree view will appear below. You can
then browse the contents to ensure the artifacts are as you expect them. Pay
particular attention to the existence of \*.asc (signature) files. If you don't
like the content of the repository, right click your repository and choose
*Drop*. You can then rollback your release (see *Canceling the Release*) and
repeat the process
-
-Note the staging repository URL, especially the number at the end of the URL.
You will need this in your vote email
+ * Note the staging repository URL, especially the number at the end of the
URL. You will need this in your vote email
## Starting the Vote
@@ -253,7 +235,7 @@ Considering that you are using a \*nix s
1. Add the key signature into the field 'OpenPGP Public Key Primary
Fingerprint' in your profile at [https://id.apache.org](https://id.apache.org)
1. You are *DONE*, but to see the changes on
[https://people.apache.org/keys/group/sling.asc](https://people.apache.org/keys/group/sling.asc)
you may need to wait a few hours
- You also have to add your public key either on pool.sks-keyservers.net or
pgp.mit.edu (for the statging repository).
+You also have to add your public key either on pool.sks-keyservers.net or
pgp.mit.edu (for the staging repository).
## Appendix B: preparing releases on Mac OS X
