ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [5/6] ant-ivy git commit: Document the upload to the nexus repository
Date Mon, 22 Dec 2014 17:37:21 GMT
Document the upload to the nexus repository


Branch: refs/heads/master
Commit: 3df94448a8f6b095a07cc2b8f0a78c1f47278094
Parents: 6d2e199
Author: Nicolas Lalevée <>
Authored: Mon Dec 22 18:21:22 2014 +0100
Committer: Nicolas Lalevée <>
Committed: Mon Dec 22 18:21:22 2014 +0100

 doc/dev/makerelease.html | 54 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/doc/dev/makerelease.html b/doc/dev/makerelease.html
index deefd80..cb0a89a 100644
--- a/doc/dev/makerelease.html
+++ b/doc/dev/makerelease.html
@@ -82,10 +82,10 @@ Be prepared to enter your passphrase several times if you use this script,
gpg w
 To be able to test the release within IvyDE, it can be deployed in the IvyDE update site.
See <a href="">that
page</a> to know how to process.
-<h3>8. Create the tag</h3>
+<h3>8. Create a signed tag</h3>
 As soon as you are happy with the artifacts to be released, it is time to tag the release
-git tag 2.0.0-beta1
+git tag -s 2.0.0-beta1 -m 'Release Ivy 2.0.0-beta1'
 And push the changes to the ASF repo
@@ -93,13 +93,28 @@ And push the changes to the ASF repo
 git push --tags 
-<h3>Publish the release candidate</h3>
+<h3>9. Publish the release candidate</h3>
 All artifacts in <tt>build/distrib</tt> except the <tt>maven2</tt>
folder needs to be published on the 'dist' svn of the ASF, in the <b>dev</b> part.
 The artifacts should be pushed in that svn folder:$VERSION
-<h3>9. Call for a vote to approve the release</h3>
+<h3>10. Publish the Maven artifact to Nexus</h3>
+Having your GPG key ID, its password, your apache ID and the associated password, just launch
ant and enter the information as required:
+ant -f build-release.xml upload-nexus
+Once uploaded, log in with your prefered web browser (use
your Apache ID).
+You should find there an <i>open</i> repository with the name of the form <tt>orgapacheant-XXXX</tt>.
It should contain the Maven artifacts: the pom, the jar, the sources, the javadocs and the
md5 and asc files.
+Now <i>close</i> the staging repository, with the description "Ivy 2.0.0-beta1".
Closing means you finished the upload and some automatic checks will run. You can see them
in the <i>Activity</i> tab of the repository.
+Once the checks passed, you can find in the <i>Summary</i> the URL of the staging
repository. It will something like:
+<h3>11. Call for a vote to approve the release</h3>
 Cast a vote to approve the release on the mailing list.
 Here is an example:
@@ -108,9 +123,13 @@ Subject: [VOTE] Ivy ${version} Release
 I have built a release candidate for Ivy ${version}
-The svn tag of this release is:;a=commit;h=SHA1-OF-THE-TAG
+The svn tag of this release is:;a=tag;h=refs/tags/2.0.0-beta1
-The artifacts has been published to:$VERSION@${svn-rev-of-the-check-in}
+The artifacts has been published to:$VERSION
at revision ${svn-rev-of-the-check-in}
+The staging maven repository is availble there:
+The Eclipse updatesite has been build there:
 Do you vote for the release of these binaries?
@@ -121,7 +140,7 @@ Regards,
 ${me}, Ivy ${version} release manager
-<h3>10. Publish the release</h3>
+<h3>12. Publish the release</h3>
 If the release is approved, it's now time to make it public. The artifacts in the <i>dev</i>
part needs to be moved into the <i>release</i> one:
@@ -130,7 +149,13 @@ $ svn mv$VERSION https://dist.ap
 In order to keep the main dist area of a reasonable size, old releases should be removed.
They will disapear from the main dist but will still be available via the <a href="">archive</a>.
To do so, just use the <tt>svn rm</tt> command against the artifacts or folders
to remove.
-<h3>11. Update the web site</h3>
+<h3>13. Promote the Maven staging repository</h3>
+Go log in with your prefered web browser (use your Apache
+Select the appropriate <tt>orgapacheant-XXXX</tt> repository and select the <i>Release</i>
+<h3>14. Update the web site</h3>
 It's time to update the download image used on the home page and the download page. Use site/images/ivy-dl.xcf
as a basis if you have <a href="">gimp</a> installed. Then
you can update the home page to refer to this image, and add a news item announcing the new
version. Update also the download page with the new image and update the links to the download
location (using a search/replace on the html source is recommended for this).
@@ -167,18 +192,21 @@ And once your happy with it, commit the changes in the source directory,
and in
 Tip: lot's of files might need to be 'added' to svn. An handy command to <tt>add</tt>
any file which is not yet under version control is the following one:
 <code>svn add --force sources</code>
-<h3>12. Deploy the Eclipse updatesite</h3>
+<h3>15. Deploy the Eclipse updatesite</h3>
 If the Eclipse update site has already been prepared to include that new Ivy release, it
is now needed to be deployed. Then follow the deployment instruction on <a href="">that
-<h3>13. Announce</h3>
+<h3>16. Announce</h3>
 Announce the release on the dev@ant.a.o, ivy-user@ant.a.o, and
mailing lists.
 You can also announce the release on popular web sites, like (xavier is the
owner of the Ivy project on freshmeat),,,, ...
-<h3>14. Update this doc</h3>
+<h3>17. Update this doc</h3>
 If you feel like anything is missing or misleading in this release doc, update it as soon
as you encounter the problem.
-<h3>15. Merge your modifications back to the master if necessary.</h3>
+<h3>18. Merge your modifications back to the master if necessary.</h3>
 Modifications on the template files do not need to be merged, but if you had troubles during
your release you may want to merge your fixes back to the trunk.
-<h3>16. Prepare next release</h3>
+<h3>19. Prepare next release</h3>
 In the master branch, update the file with the version of the next release
so that anyone building from the trunk will obtain jar with the correct version number.
 If the version just release is a final one (not an alpha, beta or rc), the list of changes
should be emptied in doc/release-notes.html, and update there the next expected version. The
announcement in the file should also be changed accordingly to the next expected version.

View raw message