|
- Instructions for making a Release:
-
- Authors: Conor MacNeill
- Stefan Bodewig
- Magesh Umasankar
- Antoine Levy-Lambert
-
- Note: This document was updated in the context of releasing Ant 1.7.
- Please interpret the branch names, tags, etc. according to
- your context.
-
- 1. Propose a release plan for vote. This should set out the timetable for
- the release under ideal circumstances.
-
- The issue of whether to create a branch for the release should be
- discussed in the release vote.
-
- The level of bugs reported can delay things. Generally, give a few
- weeks to "close" the source tree to further changes so people can
- finalise contributions, etc. At this time, the first beta will be
- cut and there will be then a period of beta testing, usually 1
- month but this should be flexible.
-
- 2. Note that any mention of a deadline causes a flood of bug fixes, new tasks,
- etc. This needs to be managed as best it can. Some fixes will be applied,
- others held over. Make this clear in the release plan. The committers and
- particularly the release manager will need to make judgement calls here.
- Anything too "big" is likely to be held over.
-
- 3. Once the freeze date arrives, create a branch for the release builds,
- if this was decided in the release vote. This was done for Ant 1.6,
- but not for Ant 1.7, nor for Ant 1.8.
-
- You will need to be comfortable in handling SVN branches with multiple
- merge-backs to the main branch and even selected merges from the the main
- branch to the release branch.
-
- For more information on performing branching and merging, please visit
- http://svnbook.red-bean.com/nightly/en/svn-book.html
-
- Label such branches ANT_16_BRANCH.
-
- 4. Once the branch is setup, the version numbers in SVN are changed. On the
- branch, the project.version property in build.xml becomes 1.7Beta.
-
- If there were a main branch, its build.xml would have 1.8alpha.
-
- [[ TODO: Check if the documentation files also need to be updated to point
- to the right areas of Ant's website. ]]
-
- 5. Before a build :
-
- the first beta on the 1.7 branch has been called 1.7.0Beta1, ...
-
- the project.version property in build.xml governs the output of
- ant -version and the naming of the distribution files.
-
- Update the following files for version number:
-
- see at the end of this document the list of files containing version information
-
- 6. Ensure you have all the external libraries that Ant uses in your
- lib/optional directory. All dependencies are either provided by
- JDK 1.5.0 or downloadable using
- ant -f fetch.xml -Ddest=optional.
- To find out whether you have all the libraries you need, execute
- the build with -verbose option and scan for lines beginning with
- "Unable to load...".
-
- 7. Make sure that your directory tree is clean by running svn status.
- Some tests leave behind leftovers which end up in the source
- distribution otherwise.
-
- 8. Next bootstrap, build and run the tests. Then build the distribution
- on the branch. It is important that this be a clean build. Label this with
- a tag ANT_170_B1.
-
- The file release.sh gives an idea of how to do this build process.
- buid.xml specifies that the code should be compiled with source=1.5 and target=1.5.
-
- C:\dev\asf\ant-core>
- svn copy https://svn.apache.org/repos/asf/ant/core/trunk \
- https://svn.apache.org/repos/asf/ant/core/tags/ANT_170_B1 \
- -m "Tagging version 1.7.0Beta1 of Ant"
-
- Revision 437509 Uebertragen.
-
- 9. Sign the distribution files using the script release/signit.xml
-
- This script requires using commons-openpgp to sign the artefacts,
-
- This tool can be checked out from
- http://svn.apache.org/repos/asf/commons/sandbox/openpgp/trunk
- You have to build it using maven
-
- You can create a property file .gnupg.properties in your home directory
- with your key id
- and pass your key passphrase on the command line with -Dpassword=****
-
- Before you do that, ensure that the key you use is inside the KEYS
- file in Ant's SVN repository
- <https://svn.apache.org/repos/asf/ant/antlibs/common/trunk/KEYS> -
- and that you copy the KEYS file to
- /www/www.apache.org/dist/ant
-
- Also make sure you have sent the key that you use to a public
- keyserver.
-
- 10. The beta distribution is now ready to go. Commit it to
- https://dist.apache.org/repos/dist/dev/ant
-
- 11. Meanwhile, convert the part of the WHATSNEW file covering the changes
- since the last release into HTML for the README file on the
- website. See the previous release directories for examples of these files.
- Add instructions and warnings (GNU tar format issues, etc).
-
- Use the target txt2html of docs.xml
-
- Name the generated file RELEASE-NOTES-x.y.z.html.
-
- Change the title to something like "Release Notes of Apache Ant
- 1.7.0Beta2" (from the default txt2html)
-
- 12. Once this is committed call for a release vote on dev@ant. The
- vote will only pass if at least three PMC members have voted +1
- and more +1s than -1s have been cast. The vote will run for a
- week.
-
- 13. Update the files listed at the end of the document (files containing
- version information) to prepare the development of the next version of Ant
-
- 14. Once the vote has passed, the distrib artifacts should be published the
- apache dist. It is managed via svnpubsub so the release should be
- committed to the subversion repository
- https://dist.apache.org/repos/dist/release/ant/.
-
- 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 archive. To do so, just use the "svn rm" command against
- the artifacts or folders to remove.
-
- 15. Address the available release tags in BugZilla. Create a new tag 1.7.0Beta1.
- If there is a separate main branch, create a 1.8alpha tag.
- Assign all existing 1.7 alpha bugs to 1.7.0Beta1.
- Note that such massive changes can be done at once by choosing the
- link "Change several bugs at once" at the bottom of the bug list
- displaying the 1.7alpha bugs.
-
- 16. Once that is done, do a test download to make sure everything is OK. A
- common problem may be:
- * the file's mime type is not recognized and is interpreted as
- text/plain. Fix it by using some .htaccess magic (AddEncoding stuff)
- * Your gz.asc files are not being displayed properly (RemoveEncoding stuff)
-
- If it looks OK, announce it on dev@ant and user@ant. After a few
- days pass and there are no major problems, a wider announcement is
- made (ant website, announce@apache.org, etc).
-
- Announce beta releases at freecode.com (Stefan Bodewig is the
- owner of Ant's project entry - bug him ;-).
-
- 17. As problems in the beta are discovered, there may be a need for
- one or more subsequent betas. The release manager makes this
- call. Each time, the versions are updated and the above process is
- repeated. Try not to have too many betas.
-
- 18. Try to advertise the need for testing of the betas as much as possible.
- This would eliminate the need to release minor patch versions like
- we had to do when releasing Ant 1.4.
-
- 19. When the final beta is considered OK, propose a vote on dev@ant to
- officially adopt the latest beta as the Ant 1.6 release. If it is passed,
- (it usually does,) this would be labelled ANT_16 and built in a similar
- fashion to the above process.
-
- It is probably a good idea to have the re-labeled distribution
- files ready in time for the vote so that no additional vote on the
- actual package is required later.
-
- 20. This time you'll have to do some house-keeping for the old
- release:
-
- * commit the new release files to
-
- from distribution
- to https://dist.apache.org/repos/dist/release/ant/[source|binaries|manual].
-
-
- * upload the maven artifacts located under java-repository/org/apache/ant
- these artifacts comprise currently for each ant jar of one POM file, the corresponding jar file
- and the corresponding GPG signatures (x.pom, x.jar, x.pom.asc, x.jar.asc)
- MD5 and SHA1 are generated by ivy during the upload
-
- to
-
- https://repository.apache.org (nexus repository)
-
- using the build file release/upload.xml
-
- ant -Dupload.user=foo -Dupload.password=secret -lib location_of_ivy_jar -f upload.xml
-
- * after the upload, you need to access the web interface of nexus under https://repository.apache.org
- login using your Apache credentials
- select the Staging enterprise repository
- expand org.apache.ant
- right click the upload that you just did
- select the context menu entry "Close"
- once this is done, you have to again select your upload in the web interface,
- right click, and select the menu entry promote.
- 4 hours later, the artefacts will be in the maven central repository.
-
-
- * Make README.html points to the new RELEASE-NOTES or is a copy of
- it.
-
- (*)
-
- 21. Update the ant.apache.org site :
-
- The website is managed here: https://svn.apache.org/repos/asf/ant/site/ant/
-
- Update the following files for version number:
-
- * source/antnews.xml (Announcement)
- * source/faq.xml (Ant's history details - not for betas)
- * source/index.xml (Announcement, latest release details, link to
- manual under "Documentation")
- * source/srcdownload.xml
- * source/bindownload.xml
- * source/manualdownload.xml
-
- Generate the html files by invoking 'ant'
- Commit the modified/generated files in the 'production' folder, it will go
- live on ant.apache.org in a matter on seconds.
-
- Change the version of the manual published on the site: change the URL in the
- svn:externals of the 'production' folder.
-
- 22. Clean up.
-
- * remove the remaining files of the previous release and betas from
- https://dist.apache.org/repos/dist/release/ant/[source|binaries|manual].
- This includes the old release notes.
-
- (+)
-
- 23. Now and perhaps during previous betas any changes on the branch must
- be merged back into the tree.
-
- 24. At this point in time, the release is done and announcements are made.
- PGP-sign your announcement posts.
-
- [[TODO: Identify the mailing lists where announcements are to be made.
- Also identify the webpages to which the announcements must go. ]]
-
- Apache mailing lists that should get the announcements:
- announce@apache.org, dev@ant and user@ant.
-
- Announce release at freecode.com
- (Stefan Bodewig is the owner of Ant's project entry - bug him ;-).
-
- 25. Add a new release tag to doap_Ant.rdf in Ant's site.
-
- 26. You can now reacquaint yourself with your family and friends.
-
- (*) Mirrors : the srcdownload.html, bindownload.html and
- manualdownload.html each list a number of mirrors. For ant 1.6.0
- the mirrors picked up the new version in 8 hours or less, the
- release having been done at midnight on Dec 18th, the mirrors had
- it on Dec 19th at 8 am. The
- srcdownload/bindownload/manualdownload pages all contain a note
- advising users to be patient immediately after the release.
-
- (+) Don't expect the old releases to disappear from
- www.apache.org/dist as soon as the new releases are there.
- The rsync process from people.a.o to www.a.o adds files once per
- hour but only deletes once per day.
-
-
- Related Information
-
- http://www.apache.org/dev/#releases
- http://commons.apache.org/releases/index.html
- http://wiki.apache.org/commons/SigningReleases
-
- Files containing version information
- ------------------------------------
-
- * manual/cover.html
- * manual/credits.html
- * build.xml properties : project.version,manifest-version,pom.version
- * POM files under src/etc/poms and subdirectories
- * ivy.xml in release subdirectory
- * WHATSNEW
- * src/etc/testcases/taskdefs/conditions/antversion.xml
-
- cover.html, credits.html, POM files, antversion.xml should be
- adjusted for the [newversion] right after the build and tagging
- of the release
-
- build.xml
- ---------
-
- right before a release :
-
- the project.version gets bumped to the exact release
- number, for instance 1.9.2
-
- right after a release :
-
- project.version property in build.xml gets bumped to
- [newversion]alpha, for example 1.9.2alpha
-
- manifest-version gets bumped to the exact next release number
- for example 1.9.2
-
- pom.version gets bumped to [newversion]-SNAPSHOT
-
-
|