cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cocoon Wiki] Update of "CocoonReleaseHowTo" by VadimGritsenko
Date Fri, 09 Mar 2007 02:29:48 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cocoon Wiki" for change notification.

The following page has been changed by VadimGritsenko:
http://wiki.apache.org/cocoon/CocoonReleaseHowTo

The comment on the change is:
change order

------------------------------------------------------------------------------
   *  LatestRelease - please update that page when a release is done
   *   To update the live demo on cocoon.zones.apache.org, see the instructions at [https://svn.apache.org/repos/private/pmc/cocoon/cocoon.zones.apache.org/admin-notes/howto-upgrade-the-release-demo.txt]
  ---- 
+ 
  = HOW TO DISTRIBUTE AN APACHE COCOON RELEASE =
  Notes on how to prepare a Cocoon release, by PierFumagalli on cocoon-dev,
  extended with a step by step procedure by CarstenZiegeler.
  
- == A) Naming Conventions: ==
- 
- The name of each downloadable archive should be named after the following
- regular expression:
- 
- {{{ PROJECT(-SUBPROJECT)?-VERSION(-VARIANT)?-(src|bin).(zip|tar.gz) }}}
- 
- Where:
-  *  PROJECT is the name of the top-level project,
-  *  SUBPROJECT is the name of the eventual subproject (optional)
-  *  VERSION is a version string (without - dashes)
-  *  VARIANT identifies the "type of distribution" (ex. win32, jdk12, linux, jdk14...) (optional)
- 
- So, in Cocoon's case, all our archives shall be called something like:
- {{{
-   cocoon-2.0.4-jdk14-bin.tar.gz
- }}}
- or
- {{{
-   cocoon-2.1m1-src.zip
- }}}
- and so on...
- 
- If one day we ever released some subproject code (for example Lenya), the
- name should be along the lines of
- {{{
-   cocoon-lenya-1.0-bin.tar.gz
- }}}
- You get the point.
- ==  B) The Release Process ==
+ ==  A) The Release Process ==
  
  ===  Code freeze ===
  Prior to the release day, a code freeze should be announced approx. 7 days in advance.
  
  ===  Announce the release process ===
- Send a simple mail to the dev list. This is in order to ensure that noone will check in
during the release process. If someone checks in during the building, testing and tagging,
the release process has to be started at the beginning again.
+ Send a simple mail to the dev list. This is in order to ensure that no one will check in
during the release process. If someone checks in during the building, testing and tagging,
the release process has to be started at the beginning again.
  
  ===  Get the version ===
- Check-out a fresh copy from the cvs on a unix platform (this is important, do not use windows!)
+ Check-out a fresh copy from the svn on a Unix platform (this is important, do not use windows!)
  
  ===  Set correct version information  ===
  Change the version information in src/java/org/apache/cocoon/cocoon.properties by
  removing "-dev" and eventually add new release information like m1, b1 etc. If this release
is a final version, change the "released.version" info to the new version as well.
- Change status.xml by adding the release with proper version and date. Also change the version
accordingly in forrest.properties.
+ Change status.xml by adding the release with proper version and date. Also change the version
accordingly in forrest.properties. But don't check-in this yet!
- But don't check-in this yet!
  
  ===  Exclude unstable blocks from the default build ===
  Edit the blocks.properties file and exclude all unstable blocks.
@@ -71, +42 @@

  
  ===  Test the distribution ===
  Uncompress the build distribution and test it. These tests should include
- different platforms (windows and Unix) and different JDKs (1.3 and 1.4).
+ different platforms (windows and Unix) and different JDKs (1.4 and 1.5).
  Testing includes building Cocoon from the release version and trying out the samples.
  Please also run 'build test'.
  
@@ -93, +64 @@

  ===  Sign the release  ===
  Therefore you have to put your public key in the KEYS file before! In addition create a
md5 file for the distribution
  
- ===  Bugtracking ===
+ ===  Bug Tracking ===
- Enter the new version into jira, so users can file entries against it.
+ Enter the new version into Jira, so users can file entries against it.
  
  ===  Upload the release ===
  Upload the release and the signatures to www.apache.org and put it
  under /www/www.apache.org/dist/cocoon into the correct directories (sources
  and binaries). Make sure that you set the permissions correctly.
  It's important to give the group write access!
- Add/change the links from the cocoon directory to the new version in
+ Add/change the links from the cocoon directory, and update
+ HEADER/README in subversion as described below in '''Publishing and Linking'''.
- the sources/binaries directory. Update the README.html and the HEADER.html in
- the SVN repository, under /cocoon/site/mirrors/.
- For more information see below.
  
- ===  Announcement ===
+ ===  End code freeze ===
  Announce to the dev list that the release process is finished and end a possible 
  code freeze.
+ 
+ ===  Update the site docs ===
+ Change the mirror.html in the cocoon-site module and update this
+ single file on the website. Update rest of the site as described
+ in the CocoonWebsiteUpdate
  
  ===  Take a break... ===
  Now wait for 24h so the mirror sites can pick up the new version.
  You can have a look at [http://www.apache.org/mirrors/] to see the status
  of the mirrors.
- 
- ===  Update mirror page ===
- Change the mirror.html in the cocoon-site module as well and update this
- single file on the website.
- For more information see below.
  
  ===  Create the announcement mail ===
  Currently this is hand-typed (or copied) - we have to reinstall the 
@@ -129, +98 @@

  ===  Register final version ===
  Enter a final version (no betas or milestones) into freshmeat.
  
- ===  Update the site docs ===
- As described in CocoonWebsiteUpdate
- 
- ===  Enter new version LatestRelease ===
+ Enter new version LatestRelease
+ 
+ Update the '''DOAP project file''' at http://svn.apache.org/repos/asf/cocoon/site/site/doap.rdf
to reflect the latest version, so that http://projects.apache.org/ is up to date
+ 
+ 
+ == B) Naming Conventions: ==
+ The name of each downloadable archive should be named after the following
+ regular expression:
+ 
+ {{{ PROJECT(-SUBPROJECT)?-VERSION(-VARIANT)?-(src|bin).(zip|tar.gz) }}}
+ 
+ Where:
+  *  PROJECT is the name of the top-level project,
+  *  SUBPROJECT is the name of the eventual subproject (optional)
+  *  VERSION is a version string (without - dashes)
+  *  VARIANT identifies the "type of distribution" (ex. win32, jdk12, linux, jdk14...) (optional)
+ 
+ So, in Cocoon's case, all our archives shall be called something like:
+ {{{
+   cocoon-2.0.4-jdk14-bin.tar.gz
+   cocoon-2.1m1-src.zip
+ }}}
+ and so on...
+ 
+ If one day we ever released some subproject code (for example Lenya), the
+ name should be along the lines of
+ {{{
+   cocoon-lenya-1.0-bin.tar.gz
+ }}}
+ You get the point.
  
  ==  C) Directories: ==
  
@@ -187, +182 @@

  \- license.txt
  }}}
  
- ==  Publishing and linking: ==
+ ==  D) Publishing and linking: ==
  
  Once the distribution ball is rolled following the naming convention and
  copied in the appropriate directory as outlined above, make sure that the
@@ -236, +231 @@

  Update the mirror.html file in subversion to link
  to latest files, and update the /www/cocoon.apache.org/ directory with these changes.
  
- ==  D) Mirroring and announcing: ==
+ ==  E) Mirroring and announcing: ==
  
  Once the release is published '''wait at least 24 hours before announcing it''' to
  the mailing lists, so that mirror sites will have the opportunity to pick
@@ -251, +246 @@

  So that people will actually '''use''' the mirrors and not peg the Foundation's
  bandwidth (which is quite expensive).
  
- Also, the '''DOAP project file''' at http://svn.apache.org/repos/asf/cocoon/site/site/doap.rdf
must be updated to reflect the latest version, so that http://projects.apache.org/ is up to
date
  
  Have fun...
  

Mime
View raw message