ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hi...@apache.org
Subject svn commit: r1635343 - in /ant/site/ivy/production/history/trunk: book.html dev/makerelease.html
Date Wed, 29 Oct 2014 23:41:45 GMT
Author: hibou
Date: Wed Oct 29 23:41:44 2014
New Revision: 1635343

URL: http://svn.apache.org/r1635343
Log:
Generate trunk version of the doc

Modified:
    ant/site/ivy/production/history/trunk/book.html
    ant/site/ivy/production/history/trunk/dev/makerelease.html

Modified: ant/site/ivy/production/history/trunk/book.html
URL: http://svn.apache.org/viewvc/ant/site/ivy/production/history/trunk/book.html?rev=1635343&r1=1635342&r2=1635343&view=diff
==============================================================================
--- ant/site/ivy/production/history/trunk/book.html (original)
+++ ant/site/ivy/production/history/trunk/book.html Wed Oct 29 23:41:44 2014
@@ -5717,36 +5717,28 @@ Before trying to implement your own, we 
 <h2>Requirements</h2>
 Requirements for making a release are similar to the requirements for building from source,
except that JDK 1.6+ and Apache Ant 1.9+ are required.<br class="xooki-br"/><h2>Procedure</h2>
 <h3>1. Check the files which needs to be updated for the release.</h3>
-On the master, check that files which require update for the release are up to date.<br
class="xooki-br"/>This includes particularly:<br class="xooki-br"/>RELEASE_NOTES<br
class="xooki-br"/>CHANGES<br class="xooki-br"/>README<br class="xooki-br"/><h3>2.
Create a release branch</h3>
-This will allow to work separately from other developers, in case you need any last modification.
For a release we have 2 branches. For instance, suppose we create a 2.0.0-beta1 release. We
have a branch for the code for all 2.0.x releases, this is the '2.0.x' branch. From this branch
we will create the release branch which is for a specific release. It is possible that the
2.0.x branch has already been created when releasing a previous version, in that case the
creation of this branch can be skipped.
+On the master, check that files which require update for the release are up to date.<br
class="xooki-br"/>This includes particularly:<br class="xooki-br"/>RELEASE_NOTES<br
class="xooki-br"/>CHANGES<br class="xooki-br"/>README<br class="xooki-br"/><h3>2.
Check out a clean copy of the branch</h3>
+Run the following git command to checkout the branch, revert any change and remove untracked
and ignored files:
 <pre>
-git branch 2.0.x master<br class="xooki-br"/>git branch 2.0.0-beta1 2.0.x
+git checkout 2.0.x<br class="xooki-br"/>git reset --hard<br class="xooki-br"/>git
clean -d -x -f
 </pre>
-<h3>3. Check out the branch</h3>
-<pre>
-git checkout 2.0.0-beta1
-</pre>
-<h3>4. Add Ivy xsd file.</h3>
+<h3>3. Add Ivy xsd file.</h3>
 You need to store the current ivy xml schema in the documentation, so that it will later
be accessible on public web site. To do so, run the following command in the directory in
which you checked out the release branch:
 <pre>
 ant -f build-release.xml release-xsd
 </pre>
 
-<h3>5. Add release note page in the documentation.</h3>
-Open the file doc/index.html with your favorite browser, and click on the plus button in
the upper right. Choose "Release Notes" as title, and "release-notes" as page id. <br class="xooki-br"/><br
class="xooki-br"/>Then edit the page (hit the first button at the upper right), and copy
the content of the RELEASE_NOTES file. You can also add the announcement for the release if
it's already ready.<br class="xooki-br"/><br class="xooki-br"/>Move the page up
in the TOC using the arrow button in the toolbar at the upper right, so that it's the first
child page under the "Documentation" page.<br class="xooki-br"/><br class="xooki-br"/>If
you take the time to make the content of the release notes more "xooki compliant" (by removing
unnecessary end of lines and adding h2 h3 and h4 tags), the page could then look like something
like that:<br class="xooki-br"/><a href="http://ant.apache.org/ivy/history/2.0.0-alpha-1.html">http://ant.apache.org/ivy/history/2.0.0-alpha-1.html</a><br
class="xooki
 -br"/><br class="xooki-br"/><h3>6. Commit your changes</h3>
+<h3>4. Add release note page in the documentation.</h3>
+Open the file doc/index.html with your favorite browser, and click on the plus button in
the upper right. Choose "Release Notes" as title, and "release-notes" as page id. <br class="xooki-br"/><br
class="xooki-br"/>Then edit the page (hit the first button at the upper right), and copy
the content of the RELEASE_NOTES file. You can also add the announcement for the release if
it's already ready.<br class="xooki-br"/><br class="xooki-br"/>Move the page up
in the TOC using the arrow button in the toolbar at the upper right, so that it's the first
child page under the "Documentation" page.<br class="xooki-br"/><br class="xooki-br"/>If
you take the time to make the content of the release notes more "xooki compliant" (by removing
unnecessary end of lines and adding h2 h3 and h4 tags), the page could then look like something
like that:<br class="xooki-br"/><a href="http://ant.apache.org/ivy/history/2.0.0-alpha-1.html">http://ant.apache.org/ivy/history/2.0.0-alpha-1.html</a><br
class="xooki
 -br"/><br class="xooki-br"/>And commit your changes:
 <pre>
 git add doc/ivy.xsd<br class="xooki-br"/>git add doc/release-notes.html<br class="xooki-br"/>git
commit -m "update templates, add release notes and ivy.xsd in documentation."
 </pre>
-<h3>7. Check that you have no pending modifications</h3>
-<pre>
-git status
-</pre>
-If your working copy is clean, you can launch the release script. If it isn't, make sure
to clean it properly. Sometimes you may need to call ant clean-all if you have started to
work with ant builds. If you are confused about your working copy state, delete it and check
it out again.<br class="xooki-br"/><h3>8. Launch the release script</h3>
+<h3>5. Launch the release script</h3>
 <pre>
 ant -f build-release.xml release
 </pre>
-The status should be release only for final releases, and milestone for any other intermediate
release.<br class="xooki-br"/>If anything is wrong, fix and go back to step 4.<br
class="xooki-br"/>If the release script is successful, release artifacts will be waiting
for you in the build/distrib directory.<br class="xooki-br"/><h3>9. Verify the
release</h3>
-Check that all zips can be opened correctly, and that running 'ant' after unzipping the source
distribution works properly.<br class="xooki-br"/>You can also do a smoke test with
the generated ivy.jar , to see if it is able to resolve properly a basic module (for instance
you can run some tutorials provided in the src/example directory in all distributions).<br
class="xooki-br"/><h3>10. Sign and upload the artifacts</h3>
+The status should be release only for final releases, and milestone for any other intermediate
release.<br class="xooki-br"/>If the release script is successful, release artifacts
will be waiting for you in the build/distrib directory.<br class="xooki-br"/><h3>6.
Verify the release</h3>
+Check that all zips can be opened correctly, and that running 'ant' after unzipping the source
distribution works properly.<br class="xooki-br"/>You can also do a smoke test with
the generated ivy.jar, to see if it is able to resolve properly a basic module (for instance
you can run some tutorials provided in the src/example directory in all distributions).<br
class="xooki-br"/><h3>7. Sign and upload the artifacts</h3>
 It's now time to sign the release artifacts and upload them to a location accessible by other
Apache commiters.<br class="xooki-br"/><br class="xooki-br"/>Here is a simple
way to sign the files using gnupg:
 <pre>
 gpg --armor --output file.zip.asc --detach-sig file.zip
@@ -5756,61 +5748,60 @@ Here is a ruby script you can use to sig
 <pre>
 require 'find'<br class="xooki-br"/><br class="xooki-br"/>Find.find('build/distrib')
do |f| <br class="xooki-br"/>    `gpg --armor --output #{f}.asc --detach-sig #{f}` if
File.file?(f) && ['.zip', '.gz', '.jar', '.pom'].include?(File.extname(f))<br class="xooki-br"/>end
 </pre>
-Be prepared to enter your passphrase several times if you use this script, gpg will ask for
your passphrase for each file to sign.<br class="xooki-br"/><br class="xooki-br"/><h3>11.
Prepare the Eclipse update site</h3>
+Be prepared to enter your passphrase several times if you use this script, gpg will ask for
your passphrase for each file to sign.<br class="xooki-br"/><br class="xooki-br"/><h3>8.
Prepare the Eclipse update site</h3>
 
-To be able to test the release within IvyDE, it can be deployed in the IvyDE update site.
See <a href="http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html">that
page</a> to know how to process.<br class="xooki-br"/><br class="xooki-br"/><h3>12.
Create the tag</h3>
-As soon as you are happy with the artifacts to be released, it is time to tag the svn repo
+To be able to test the release within IvyDE, it can be deployed in the IvyDE update site.
See <a href="http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html">that
page</a> to know how to process.<br class="xooki-br"/><br class="xooki-br"/><h3>9.
Create the tag</h3>
+As soon as you are happy with the artifacts to be released, it is time to tag the release
 <pre>
 git tag 2.0.0-beta1
 </pre>
 
 <h3>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.<br
class="xooki-br"/><br class="xooki-br"/>The artifacts should be pushed in that svn
folder: <a href="https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION">https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION</a><br
class="xooki-br"/><br class="xooki-br"/><h3>13. Call for a vote to approve
the release</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.<br
class="xooki-br"/><br class="xooki-br"/>The artifacts should be pushed in that svn
folder: <a href="https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION">https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION</a><br
class="xooki-br"/><br class="xooki-br"/><h3>10. Call for a vote to approve
the release</h3>
 Cast a vote to approve the release on the dev@ant.apache.org mailing list.<br class="xooki-br"/><br
class="xooki-br"/>Here is an example:
 <pre>
 Subject: [VOTE] Ivy ${version} Release<br class="xooki-br"/><br class="xooki-br"/>I
have built a release candidate for Ivy ${version}<br class="xooki-br"/><br class="xooki-br"/>The
svn tag of this release is: <a href="https://svn.apache.org/repos/asf/ant/ivy/core/tags/${version}@${svn-rev-of-the-tag">https://svn.apache.org/repos/asf/ant/ivy/core/tags/${version}@${svn-rev-of-the-tag</a>}<br
class="xooki-br"/><br class="xooki-br"/>The artifacts has been published to: <a
href="https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION@${svn-rev-of-the-check-in">https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION@${svn-rev-of-the-check-in</a>}<br
class="xooki-br"/><br class="xooki-br"/>Do you vote for the release of these binaries?<br
class="xooki-br"/><br class="xooki-br"/>[ ] Yes<br class="xooki-br"/>[ ] No<br
class="xooki-br"/><br class="xooki-br"/>Regards,<br class="xooki-br"/><br
class="xooki-br"/>${me}, Ivy ${version} release manager
 </pre>
-<h3>14. Publish the release</h3>
+<h3>11. 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:
 <pre>
 $ svn mv <a href="https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION">https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION</a>
<a href="https://dist.apache.org/repos/dist/release/ant/ivy/$VERSION">https://dist.apache.org/repos/dist/release/ant/ivy/$VERSION</a>
 </pre>
 
-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="http://archive.apache.org/dist/ant/ivy/">archive</a>.
To do so, just use the <tt>svn rm</tt> command against the artifacts or folders
to remove.<br class="xooki-br"/><br class="xooki-br"/><h3>15. Update the
web site</h3>
-Add a link to the released version documentation in the web site. <br class="xooki-br"/><br
class="xooki-br"/>To do so, you need to:<br class="xooki-br"/><ol>
-<li>add a svn externals reference to the documentation</li>
-edit the svn properties of site/history, and in the svn:externals property, add a line like
this one:
-<pre>
-2.0.0-beta1 <a href="https://svn.apache.org/repos/asf/ant/ivy/core/branches/2.0.0-beta1/doc">https://svn.apache.org/repos/asf/ant/ivy/core/branches/2.0.0-beta1/doc</a>
-</pre>
-You should also change the latest-milestone external link.<br class="xooki-br"/><br
class="xooki-br"/>You can use "svn propedit svn:externals path/to/history" to do so.<br
class="xooki-br"/><br class="xooki-br"/>Once you've changed the property, use "svn
up" to checkout the proper documentation.
+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="http://archive.apache.org/dist/ant/ivy/">archive</a>.
To do so, just use the <tt>svn rm</tt> command against the artifacts or folders
to remove.<br class="xooki-br"/><br class="xooki-br"/><h3>12. 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="http://www.gimp.org/">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).<br class="xooki-br"/><br
class="xooki-br"/>The just release documentation should be added to the site. To do so,
you need to:<br class="xooki-br"/><ol>
 <li>edit the toc.json file in the site component of Ivy</li>
-and add something like that:
+and add a piece of json with a title and an url; note that the version in the url must be
the same as the tag in the git repo.
 <pre>
 {<br class="xooki-br"/>   "title":"2.0.0-beta1",<br class="xooki-br"/>   "url":"<a
href="http://ant.apache.org/ivy/history/2.0.0-beta1/index.html">http://ant.apache.org/ivy/history/2.0.0-beta1/index.html</a>"<br
class="xooki-br"/>}
 </pre>
-You can also edit the title of the main documentation node pointing to latest-milestone /
latest-release if necessary.<br class="xooki-br"/></ol>
-
-Then you can update the release notes page of the imported documentation if necessary, to
include the announcement for example.<br class="xooki-br"/><br class="xooki-br"/>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="http://www.gimp.org/">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).<br class="xooki-br"/><br
class="xooki-br"/>All site editing being done, commit your changes.<br class="xooki-br"/><br
class="xooki-br"/>And now let's generate the site and deploy it:<br class="xooki-br"/><ol>
-    <li>generate the part of the site for the new version:</li>
+<li>generate the part of the site for the new version:</li>
 <pre>
-ant generate-history -Dhistory.version=2.0.0-beta1
+ant checkout-history -Dhistory.version=2.0.0-beta1<br class="xooki-br"/>ant generate-history
-Dhistory.version=2.0.0-beta1
 </pre>
-<u>WARNING:</u> that target is modifiying the toc.json in the imported branch
so that the generated html have a proper version declared in the toc. You should not commit
that change. Once the site has been generated, you may want to revert the changes so you won't
commit it by mistake. (TODO: process to improve so we shouldn't worry).<br class="xooki-br"/>
   <li>generate the website with the new toc:</li>
+<li>if the 'latest-milestone' needs to be update too, run:</li>
 <pre>
-ant /all generate-site
+ant checkout-history -Dhistory.version=2.0.0-beta1 -Dtarget.history.folder=latest-milestone
 </pre>
-    <li>you should verify that the site generated in the production directory is OK.
And once your happy with it, commit the changes (some svn add might be needed !)</li>
 </ol>
 
-<h3>16. Deploy the Eclipse updatesite</h3>
+Now let's generate the website with the new toc:
+<pre>
+ant /all generate-site
+</pre>
+
+You should verify that the site generated in the production directory is OK. You can open
the files with your prefered web browser like it was deployed.<br class="xooki-br"/><br
class="xooki-br"/>And once your happy with it, commit the changes in the source directory,
and in the production directoy to get it actually deployed via svnpubsub.<br class="xooki-br"/><br
class="xooki-br"/>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:
+<pre>svn add --force sources</pre>
+
+<h3>13. 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="http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html">that
page</a>.<br class="xooki-br"/><br class="xooki-br"/><h3>17. Announce</h3>
-Announce the release on the dev@ant.a.o, ivy-user@ant.a.o, user@ant.apache.org and announce@apache.org
mailing lists.<br class="xooki-br"/>You can also announce the release on popular web
sites, like freshmeat.net (xavier is the owner of the Ivy project on freshmeat), javalobby.org,
theserverside.com, dzone.com, ...<br class="xooki-br"/><h3>16. 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.<br class="xooki-br"/><h3>17. Merge your modifications
back to the trunk 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.<br class="xooki-br"/><h3>18.
Prepare next release</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="http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html">that
page</a>.<br class="xooki-br"/><br class="xooki-br"/><h3>14. Announce</h3>
+Announce the release on the dev@ant.a.o, ivy-user@ant.a.o, user@ant.apache.org and announce@apache.org
mailing lists.<br class="xooki-br"/>You can also announce the release on popular web
sites, like freshmeat.net (xavier is the owner of the Ivy project on freshmeat), javalobby.org,
theserverside.com, dzone.com, ...<br class="xooki-br"/><h3>15. 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.<br class="xooki-br"/><h3>16. Merge your modifications
back to the trunk 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.<br class="xooki-br"/><h3>17.
Prepare next release</h3>
 Update the file version.properties with the version of the next release so that anyone building
from the trunk will obtain jar with the correct version number.<br class="xooki-br"/><br
class="xooki-br"/>Release the version in <a href="https://issues.apache.org/jira/browse/IVY">jira</a>,
and create a new unreleased version for the next planned version.
  		</div><!-- main -->
 

Modified: ant/site/ivy/production/history/trunk/dev/makerelease.html
URL: http://svn.apache.org/viewvc/ant/site/ivy/production/history/trunk/dev/makerelease.html?rev=1635343&r1=1635342&r2=1635343&view=diff
==============================================================================
--- ant/site/ivy/production/history/trunk/dev/makerelease.html (original)
+++ ant/site/ivy/production/history/trunk/dev/makerelease.html Wed Oct 29 23:41:44 2014
@@ -241,36 +241,28 @@
 <h2>Requirements</h2>
 Requirements for making a release are similar to the requirements for building from source,
except that JDK 1.6+ and Apache Ant 1.9+ are required.<br class="xooki-br"/><h2>Procedure</h2>
 <h3>1. Check the files which needs to be updated for the release.</h3>
-On the master, check that files which require update for the release are up to date.<br
class="xooki-br"/>This includes particularly:<br class="xooki-br"/>RELEASE_NOTES<br
class="xooki-br"/>CHANGES<br class="xooki-br"/>README<br class="xooki-br"/><h3>2.
Create a release branch</h3>
-This will allow to work separately from other developers, in case you need any last modification.
For a release we have 2 branches. For instance, suppose we create a 2.0.0-beta1 release. We
have a branch for the code for all 2.0.x releases, this is the '2.0.x' branch. From this branch
we will create the release branch which is for a specific release. It is possible that the
2.0.x branch has already been created when releasing a previous version, in that case the
creation of this branch can be skipped.
+On the master, check that files which require update for the release are up to date.<br
class="xooki-br"/>This includes particularly:<br class="xooki-br"/>RELEASE_NOTES<br
class="xooki-br"/>CHANGES<br class="xooki-br"/>README<br class="xooki-br"/><h3>2.
Check out a clean copy of the branch</h3>
+Run the following git command to checkout the branch, revert any change and remove untracked
and ignored files:
 <pre>
-git branch 2.0.x master<br class="xooki-br"/>git branch 2.0.0-beta1 2.0.x
+git checkout 2.0.x<br class="xooki-br"/>git reset --hard<br class="xooki-br"/>git
clean -d -x -f
 </pre>
-<h3>3. Check out the branch</h3>
-<pre>
-git checkout 2.0.0-beta1
-</pre>
-<h3>4. Add Ivy xsd file.</h3>
+<h3>3. Add Ivy xsd file.</h3>
 You need to store the current ivy xml schema in the documentation, so that it will later
be accessible on public web site. To do so, run the following command in the directory in
which you checked out the release branch:
 <pre>
 ant -f build-release.xml release-xsd
 </pre>
 
-<h3>5. Add release note page in the documentation.</h3>
-Open the file doc/index.html with your favorite browser, and click on the plus button in
the upper right. Choose "Release Notes" as title, and "release-notes" as page id. <br class="xooki-br"/><br
class="xooki-br"/>Then edit the page (hit the first button at the upper right), and copy
the content of the RELEASE_NOTES file. You can also add the announcement for the release if
it's already ready.<br class="xooki-br"/><br class="xooki-br"/>Move the page up
in the TOC using the arrow button in the toolbar at the upper right, so that it's the first
child page under the "Documentation" page.<br class="xooki-br"/><br class="xooki-br"/>If
you take the time to make the content of the release notes more "xooki compliant" (by removing
unnecessary end of lines and adding h2 h3 and h4 tags), the page could then look like something
like that:<br class="xooki-br"/><a href="http://ant.apache.org/ivy/history/2.0.0-alpha-1.html">http://ant.apache.org/ivy/history/2.0.0-alpha-1.html</a><br
class="xooki
 -br"/><br class="xooki-br"/><h3>6. Commit your changes</h3>
+<h3>4. Add release note page in the documentation.</h3>
+Open the file doc/index.html with your favorite browser, and click on the plus button in
the upper right. Choose "Release Notes" as title, and "release-notes" as page id. <br class="xooki-br"/><br
class="xooki-br"/>Then edit the page (hit the first button at the upper right), and copy
the content of the RELEASE_NOTES file. You can also add the announcement for the release if
it's already ready.<br class="xooki-br"/><br class="xooki-br"/>Move the page up
in the TOC using the arrow button in the toolbar at the upper right, so that it's the first
child page under the "Documentation" page.<br class="xooki-br"/><br class="xooki-br"/>If
you take the time to make the content of the release notes more "xooki compliant" (by removing
unnecessary end of lines and adding h2 h3 and h4 tags), the page could then look like something
like that:<br class="xooki-br"/><a href="http://ant.apache.org/ivy/history/2.0.0-alpha-1.html">http://ant.apache.org/ivy/history/2.0.0-alpha-1.html</a><br
class="xooki
 -br"/><br class="xooki-br"/>And commit your changes:
 <pre>
 git add doc/ivy.xsd<br class="xooki-br"/>git add doc/release-notes.html<br class="xooki-br"/>git
commit -m "update templates, add release notes and ivy.xsd in documentation."
 </pre>
-<h3>7. Check that you have no pending modifications</h3>
-<pre>
-git status
-</pre>
-If your working copy is clean, you can launch the release script. If it isn't, make sure
to clean it properly. Sometimes you may need to call ant clean-all if you have started to
work with ant builds. If you are confused about your working copy state, delete it and check
it out again.<br class="xooki-br"/><h3>8. Launch the release script</h3>
+<h3>5. Launch the release script</h3>
 <pre>
 ant -f build-release.xml release
 </pre>
-The status should be release only for final releases, and milestone for any other intermediate
release.<br class="xooki-br"/>If anything is wrong, fix and go back to step 4.<br
class="xooki-br"/>If the release script is successful, release artifacts will be waiting
for you in the build/distrib directory.<br class="xooki-br"/><h3>9. Verify the
release</h3>
-Check that all zips can be opened correctly, and that running 'ant' after unzipping the source
distribution works properly.<br class="xooki-br"/>You can also do a smoke test with
the generated ivy.jar , to see if it is able to resolve properly a basic module (for instance
you can run some tutorials provided in the src/example directory in all distributions).<br
class="xooki-br"/><h3>10. Sign and upload the artifacts</h3>
+The status should be release only for final releases, and milestone for any other intermediate
release.<br class="xooki-br"/>If the release script is successful, release artifacts
will be waiting for you in the build/distrib directory.<br class="xooki-br"/><h3>6.
Verify the release</h3>
+Check that all zips can be opened correctly, and that running 'ant' after unzipping the source
distribution works properly.<br class="xooki-br"/>You can also do a smoke test with
the generated ivy.jar, to see if it is able to resolve properly a basic module (for instance
you can run some tutorials provided in the src/example directory in all distributions).<br
class="xooki-br"/><h3>7. Sign and upload the artifacts</h3>
 It's now time to sign the release artifacts and upload them to a location accessible by other
Apache commiters.<br class="xooki-br"/><br class="xooki-br"/>Here is a simple
way to sign the files using gnupg:
 <pre>
 gpg --armor --output file.zip.asc --detach-sig file.zip
@@ -280,61 +272,60 @@ Here is a ruby script you can use to sig
 <pre>
 require 'find'<br class="xooki-br"/><br class="xooki-br"/>Find.find('build/distrib')
do |f| <br class="xooki-br"/>    `gpg --armor --output #{f}.asc --detach-sig #{f}` if
File.file?(f) && ['.zip', '.gz', '.jar', '.pom'].include?(File.extname(f))<br class="xooki-br"/>end
 </pre>
-Be prepared to enter your passphrase several times if you use this script, gpg will ask for
your passphrase for each file to sign.<br class="xooki-br"/><br class="xooki-br"/><h3>11.
Prepare the Eclipse update site</h3>
+Be prepared to enter your passphrase several times if you use this script, gpg will ask for
your passphrase for each file to sign.<br class="xooki-br"/><br class="xooki-br"/><h3>8.
Prepare the Eclipse update site</h3>
 
-To be able to test the release within IvyDE, it can be deployed in the IvyDE update site.
See <a href="http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html">that
page</a> to know how to process.<br class="xooki-br"/><br class="xooki-br"/><h3>12.
Create the tag</h3>
-As soon as you are happy with the artifacts to be released, it is time to tag the svn repo
+To be able to test the release within IvyDE, it can be deployed in the IvyDE update site.
See <a href="http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html">that
page</a> to know how to process.<br class="xooki-br"/><br class="xooki-br"/><h3>9.
Create the tag</h3>
+As soon as you are happy with the artifacts to be released, it is time to tag the release
 <pre>
 git tag 2.0.0-beta1
 </pre>
 
 <h3>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.<br
class="xooki-br"/><br class="xooki-br"/>The artifacts should be pushed in that svn
folder: <a href="https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION">https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION</a><br
class="xooki-br"/><br class="xooki-br"/><h3>13. Call for a vote to approve
the release</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.<br
class="xooki-br"/><br class="xooki-br"/>The artifacts should be pushed in that svn
folder: <a href="https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION">https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION</a><br
class="xooki-br"/><br class="xooki-br"/><h3>10. Call for a vote to approve
the release</h3>
 Cast a vote to approve the release on the dev@ant.apache.org mailing list.<br class="xooki-br"/><br
class="xooki-br"/>Here is an example:
 <pre>
 Subject: [VOTE] Ivy ${version} Release<br class="xooki-br"/><br class="xooki-br"/>I
have built a release candidate for Ivy ${version}<br class="xooki-br"/><br class="xooki-br"/>The
svn tag of this release is: <a href="https://svn.apache.org/repos/asf/ant/ivy/core/tags/${version}@${svn-rev-of-the-tag">https://svn.apache.org/repos/asf/ant/ivy/core/tags/${version}@${svn-rev-of-the-tag</a>}<br
class="xooki-br"/><br class="xooki-br"/>The artifacts has been published to: <a
href="https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION@${svn-rev-of-the-check-in">https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION@${svn-rev-of-the-check-in</a>}<br
class="xooki-br"/><br class="xooki-br"/>Do you vote for the release of these binaries?<br
class="xooki-br"/><br class="xooki-br"/>[ ] Yes<br class="xooki-br"/>[ ] No<br
class="xooki-br"/><br class="xooki-br"/>Regards,<br class="xooki-br"/><br
class="xooki-br"/>${me}, Ivy ${version} release manager
 </pre>
-<h3>14. Publish the release</h3>
+<h3>11. 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:
 <pre>
 $ svn mv <a href="https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION">https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION</a>
<a href="https://dist.apache.org/repos/dist/release/ant/ivy/$VERSION">https://dist.apache.org/repos/dist/release/ant/ivy/$VERSION</a>
 </pre>
 
-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="http://archive.apache.org/dist/ant/ivy/">archive</a>.
To do so, just use the <tt>svn rm</tt> command against the artifacts or folders
to remove.<br class="xooki-br"/><br class="xooki-br"/><h3>15. Update the
web site</h3>
-Add a link to the released version documentation in the web site. <br class="xooki-br"/><br
class="xooki-br"/>To do so, you need to:<br class="xooki-br"/><ol>
-<li>add a svn externals reference to the documentation</li>
-edit the svn properties of site/history, and in the svn:externals property, add a line like
this one:
-<pre>
-2.0.0-beta1 <a href="https://svn.apache.org/repos/asf/ant/ivy/core/branches/2.0.0-beta1/doc">https://svn.apache.org/repos/asf/ant/ivy/core/branches/2.0.0-beta1/doc</a>
-</pre>
-You should also change the latest-milestone external link.<br class="xooki-br"/><br
class="xooki-br"/>You can use "svn propedit svn:externals path/to/history" to do so.<br
class="xooki-br"/><br class="xooki-br"/>Once you've changed the property, use "svn
up" to checkout the proper documentation.
+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="http://archive.apache.org/dist/ant/ivy/">archive</a>.
To do so, just use the <tt>svn rm</tt> command against the artifacts or folders
to remove.<br class="xooki-br"/><br class="xooki-br"/><h3>12. 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="http://www.gimp.org/">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).<br class="xooki-br"/><br
class="xooki-br"/>The just release documentation should be added to the site. To do so,
you need to:<br class="xooki-br"/><ol>
 <li>edit the toc.json file in the site component of Ivy</li>
-and add something like that:
+and add a piece of json with a title and an url; note that the version in the url must be
the same as the tag in the git repo.
 <pre>
 {<br class="xooki-br"/>   "title":"2.0.0-beta1",<br class="xooki-br"/>   "url":"<a
href="http://ant.apache.org/ivy/history/2.0.0-beta1/index.html">http://ant.apache.org/ivy/history/2.0.0-beta1/index.html</a>"<br
class="xooki-br"/>}
 </pre>
-You can also edit the title of the main documentation node pointing to latest-milestone /
latest-release if necessary.<br class="xooki-br"/></ol>
-
-Then you can update the release notes page of the imported documentation if necessary, to
include the announcement for example.<br class="xooki-br"/><br class="xooki-br"/>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="http://www.gimp.org/">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).<br class="xooki-br"/><br
class="xooki-br"/>All site editing being done, commit your changes.<br class="xooki-br"/><br
class="xooki-br"/>And now let's generate the site and deploy it:<br class="xooki-br"/><ol>
-    <li>generate the part of the site for the new version:</li>
+<li>generate the part of the site for the new version:</li>
 <pre>
-ant generate-history -Dhistory.version=2.0.0-beta1
+ant checkout-history -Dhistory.version=2.0.0-beta1<br class="xooki-br"/>ant generate-history
-Dhistory.version=2.0.0-beta1
 </pre>
-<u>WARNING:</u> that target is modifiying the toc.json in the imported branch
so that the generated html have a proper version declared in the toc. You should not commit
that change. Once the site has been generated, you may want to revert the changes so you won't
commit it by mistake. (TODO: process to improve so we shouldn't worry).<br class="xooki-br"/>
   <li>generate the website with the new toc:</li>
+<li>if the 'latest-milestone' needs to be update too, run:</li>
 <pre>
-ant /all generate-site
+ant checkout-history -Dhistory.version=2.0.0-beta1 -Dtarget.history.folder=latest-milestone
 </pre>
-    <li>you should verify that the site generated in the production directory is OK.
And once your happy with it, commit the changes (some svn add might be needed !)</li>
 </ol>
 
-<h3>16. Deploy the Eclipse updatesite</h3>
+Now let's generate the website with the new toc:
+<pre>
+ant /all generate-site
+</pre>
+
+You should verify that the site generated in the production directory is OK. You can open
the files with your prefered web browser like it was deployed.<br class="xooki-br"/><br
class="xooki-br"/>And once your happy with it, commit the changes in the source directory,
and in the production directoy to get it actually deployed via svnpubsub.<br class="xooki-br"/><br
class="xooki-br"/>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:
+<pre>svn add --force sources</pre>
+
+<h3>13. 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="http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html">that
page</a>.<br class="xooki-br"/><br class="xooki-br"/><h3>17. Announce</h3>
-Announce the release on the dev@ant.a.o, ivy-user@ant.a.o, user@ant.apache.org and announce@apache.org
mailing lists.<br class="xooki-br"/>You can also announce the release on popular web
sites, like freshmeat.net (xavier is the owner of the Ivy project on freshmeat), javalobby.org,
theserverside.com, dzone.com, ...<br class="xooki-br"/><h3>16. 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.<br class="xooki-br"/><h3>17. Merge your modifications
back to the trunk 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.<br class="xooki-br"/><h3>18.
Prepare next release</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="http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html">that
page</a>.<br class="xooki-br"/><br class="xooki-br"/><h3>14. Announce</h3>
+Announce the release on the dev@ant.a.o, ivy-user@ant.a.o, user@ant.apache.org and announce@apache.org
mailing lists.<br class="xooki-br"/>You can also announce the release on popular web
sites, like freshmeat.net (xavier is the owner of the Ivy project on freshmeat), javalobby.org,
theserverside.com, dzone.com, ...<br class="xooki-br"/><h3>15. 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.<br class="xooki-br"/><h3>16. Merge your modifications
back to the trunk 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.<br class="xooki-br"/><h3>17.
Prepare next release</h3>
 Update the file version.properties with the version of the next release so that anyone building
from the trunk will obtain jar with the correct version number.<br class="xooki-br"/><br
class="xooki-br"/>Release the version in <a href="https://issues.apache.org/jira/browse/IVY">jira</a>,
and create a new unreleased version for the next planned version.
  		</div><!-- main -->
 		</td>



Mime
View raw message