db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "DerbySnapshotOrRelease" by DyreTjeldvoll
Date Wed, 30 Apr 2008 17:20:13 GMT
Dear Wiki user,

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

The following page has been changed by DyreTjeldvoll:
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease

------------------------------------------------------------------------------
   1. [[Anchor(VersionInJIRA)]] Arrange for the new version(s) in JIRA.
    Unless you are a Jira-admin you need to post to derby-dev requesting that new versions
be added to JIRA. For any release you need a new version for the (beta) release candidate.
When creating a new branch you also need a new development version for trunk, (unless this
has been done earlier for some reason).
  
-  1. Target the bugs you feel should be fixed in JIRA
+  1. [[Anchor(TargetBugs)]] Target the bugs you feel should be fixed in JIRA
  
    All features and bug fixes should be tracked in JIRA: http://issues.apache.org/jira/browse/DERBY
  
@@ -405, +405 @@

  ==== During the vote ====
  
   1. Address items on the ReleaseVettingChecklist
- 
    Make sure that the community addresses relevant items on the ReleaseVettingChecklist.
  
  ==== After an unsuccessful vote ====
  
+  1. If vote does not pass and go back to [#TargetBugs targeting bugs in Jira].
-  1. If vote does not pass and go back to 'Drive bug list to zero'.
- 
-   If the vote does not pass and additional release candidates need to be made, then presumably
it won't have passed because of a showstopper-type bug or similar issue. So, go back to the
bug-fixing section.
+   If the vote does not pass and additional release candidates need to be made, then presumably
it won't have passed because of a showstopper-type bug or similar issue, so you need to go
back to the bug-fixing section.
  
  === After a successful vote ===
  
   1. If the vote passes, put distributions onto mirrors
  
-   First, read:
+   {i} First, read Apache's information about mirroring: http://www.apache.org/dev/mirrors.html
and http://www.apache.org/dev/mirror-step-by-step.html
  
-   http://www.apache.org/dev/mirrors.html and
-   http://www.apache.org/dev/mirror-step-by-step.html
- 
-   Copy the distribution archives and their signatures/checksums to a new directory underneath
/www/www.apache.org/dist/db/derby on people.apache.org.
+   Copy the distribution archives and their signatures/checksums to a new directory underneath
`/www/www.apache.org/dist/db/derby` on `people.apache.org`.
  
    If the new release is the most current release, link the -current links to the new files.
Here's a quick-and-dirty shell script for doing so:
  
@@ -447, +442 @@

  
    using db-derby-10.1.1.0 as the release to link to -current as an example.
  
+  
-   If this release supercedes a previous release on a branch, be sure to move the old files
to the archive. It is important that we keep our mirror directory tidy.
- 
- 
   1. Create a page for the release, build/update site
  
    For instructions on how to build the website using Forrest, please see: [http://db.apache.org/derby/papers/derby_web.html]
  
   It is a good idea to use the previous release pages as templates, filling in the changed
details as necessary. You should add a .cgi and a .html file for the release. The main thing
to remember is that the .cgi file should have the same name as the .html file. 
  
-  a. Update the derby_downloads.xml page in the src/documentation/content/xdocs directory
so that the links to the new files are included.
+   a. Update the derby_downloads.xml page in the src/documentation/content/xdocs directory
so that the links to the new files are included.
-  Note the following things when creating the release page:
+    Note the following things when creating the release page:
    * Be sure to specify that the src.tar.gz requires gnu tar to unravel (because of our usage
of ant tar to create this, using longfile=gnu for handling long filenames).
    * Forrest will not copy the release .cgi script over unless you make a link to it from
another page. Add the link to derby_downloads.html before building.
    * Remove all square brackets [] from the release notes page. When the cgi machinery sees
square brackets, it truncates the release page.
@@ -466, +459 @@

    * In order for the release HTML file to be pulled into the build, it is necessary to add
a line to the <uris> section of src/documentation/conf/cli.xconf. Near line 310 of that
file, add: <uri type="append" src="releases/release-10.1.2.1.html"/> (with the correct
version for your release)
    * Svn delete the cgi script for the previous release. Also, edit its release page to remove
the cgi boilerplate and convert the distribution links from mirror references to ordinary
links. This means removing the [preferred] tags. To see what this should look like, look at
the release page for an even older release.
    * Subversion may report some files as changed which should be static. Revert anything
in build/site/skin or build/site/papers before committing your website changes ([http://db.apache.org/derby/papers/derby_web.html#odd_diffs
see the explanation]).
-  b. Run 'forrest site' at the top of the site tree.
+   a. Run 'forrest site' at the top of the site tree.
  
-  Due to [http://issues.apache.org/jira/browse/FOR-480]FOR-480, the release page will be
built into your $FORREST_HOME/main/site directory. You will need to copy it to the build directory.
+    Due to [http://issues.apache.org/jira/browse/FOR-480]FOR-480, the release page will be
built into your $FORREST_HOME/main/site directory. You will need to copy it to the build directory.
  
-  c. Check the changes. If they look good, 'svn commit' them. NOTE: you should revert any
changed files in build/tmp or build/site/skin. But you should check in other updated files.
+   a. Check the changes. If they look good, 'svn commit' them. NOTE: you should revert any
changed files in build/tmp or build/site/skin. But you should check in other updated files.
  
-  d. Update the website on people.apache.org by logging into the machine and doing:
+   a. Update the website on people.apache.org by logging into the machine and doing:
  
-  {{{cd /www/db.apache.org/derby
+    {{{cd /www/db.apache.org/derby
  svn up}}}
  
     Note that people.apache.org is rsync'd to the actual website every hour or so. Verify
that the changes appear on the Derby website at http://db.apache.org/derby/derby_downloads.html
  
-   Also, when you run 'svn up' on people.apache.org, make sure that the new .cgi file is
executable and otherwise has the correct permissions!
+    Also, when you run 'svn up' on people.apache.org, make sure that the new .cgi file is
executable and otherwise has the correct permissions!
  
-   Once you have committed your changes and updated the website on people, you can review
your changes by following the instructions at http://www.apache.org/dev/project-site.html
+   a. Once you have committed your changes and updated the website on people, you can review
your changes by following the instructions at http://www.apache.org/dev/project-site.html
  
+   a. If you removed mirroring for an existing release (by removing the CGI script and changing
the links), you should now delete those releases from the mirror directory as it is important
to keep the mirror directory tidy. 
+    <!> Don't delete them until you have verified that the updated web page with new
links to the archive directory actually works.
+ 
+    {i} It is no longer necessary to manually copy releases to the archive. Anything placed
in the mirror directory (`/www/www.apache.org/dist/db/derby`) will automatically be copied
to the archive directory (`/www/archive.apache.org/dist/db/derby`).
+  
  
   1. Deploy to Maven repository.
  

Mime
View raw message