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 RichardHillegas
Date Tue, 12 Oct 2010 18:10:33 GMT
Dear Wiki user,

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

The "DerbySnapshotOrRelease" page has been changed by RichardHillegas.


  For each release candidate:
    * Adjust Release Notes as necessary.
    * Adjust JIRA release ids and fix showstoppers which flunked the previous release candidate.
-   * Publish new distributions and call a vote to vet them.
+   * Build new distributions and call a vote to vet them.
  Once after candidate passes vote:
+   * Deploy distributions to the Apache mirrors.
+   * Deploy distributions to the maven repository.
+   * Tag the release and update miscellaneous references.
-   * tally vote & announce
-   * put files on mirrors
-   * create doc directory (for new branches) and copy documention from the new release
-   * create web page for release
-   * possibly remove old versions from the mirror directory 
-   * deploy to maven repository
-   * announce release
+   * Announce the new release.
-   * tag release and check in the jars (for upgrade testing)
-   * update the News section of the web site
-   * update the wiki's Front Page
-   * merge development versions in Jira
-   * update `STATUS` file
  == Release process steps details ==
- === Preparation for the Release ===
+ === Preparation ===
  See ReleasePrep
@@ -38, +30 @@

  See ReleaseCandidates
+ === Publication ===
+ See ReleasePublication
- === After a successful vote ===
-  1. If the vote passes, put distributions onto mirrors
-   {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
-   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:
-   {{{
- ln -s $1/$1-bin.tar.gz db-derby-current-bin.tar.gz
- ln -s $1/$1-bin.tar.gz.asc db-derby-current-bin.tar.gz.asc
- ln -s $1/$1-bin.tar.gz.md5 db-derby-current-bin.tar.gz.md5
- ln -s $1/$1-bin.zip db-derby-current-bin.zip
- ln -s $1/$1-bin.zip.asc db-derby-current-bin.zip.asc
- ln -s $1/$1-bin.zip.md5 db-derby-current-bin.zip.md5
- ln -s $1/$1-src.tar.gz db-derby-current-src.tar.gz
- ln -s $1/$1-src.tar.gz.asc db-derby-current-src.tar.gz.asc
- ln -s $1/$1-src.tar.gz.md5 db-derby-current-src.tar.gz.md5
- ln -s $1/$1-src.zip db-derby-current-src.zip
- ln -s $1/$1-src.zip.asc db-derby-current-src.zip.asc
- ln -s $1/$1-src.zip.md5 db-derby-current-src.zip.md5}}}
-   which, if you called the script linkcurrent.sh and put it in your home directory, could
be run as follows:
-   {{{
- cd /www/www.apache.org/dist/db/derby
- ~/linkcurrent.sh db-derby-}}}
-   using db-derby- as the release to link to -current as an example.
-  1. Copy the latest version of the documentation to the doc directory on the website. 
-   The documentation is included in the release you uploaded, but unfortunately its directory
structure is not quite right for the website. To get around this you need to unzip the `db-derby-x.y.z.w-bin.zip`
archive, rename some directories and copy the pdf files into the html hierarchy. Here is a
shell script outlining the process:
-   {{{
- mkdir ~/x.y
- cd ~/x.y
- unzip $1
- mv db*bin/docs .
- mv db*bin/javadoc ./publishedapi
- rm -r db*bin
- for i in adminguide devguide getstart ref tools tuning
- do
-   mv docs/pdf/$i/*.pdf docs/html/$i
-   rmdir docs/pdf/$i
- done
- mv docs/html/* .
- rmdir docs/html
- rm -rf docs/pdf/pt_BR
- rm -rf docs/pdf/ja_JP
- rmdir docs/pdf
- rmdir docs
- }}}
-   Pass in the location of the `db-derby-x.y.z.w-bin.zip`. Move the x.y directory that gets
created in your home directory over to `/www/db.apache.org/derby/docs`.
-   (!) It is probably easier (especially if you have a high-latency connection to `people.apache.org`),
to create the x.y directory on the same machine where you built the release, but then you
need to upload the documention directory. A recursive copy using scp is going to take a long
time, so it is better to create an archive and copy that:
-   {{{
- zip -r x.y.zip x.y
- scp x.y.zip you@people.apache.org:/www/db.apache.org/derby/docs/
- ssh you@people.apache.org
- cd /www/db.apache.org/derby/docs/
- unzip x.y.zip
- rm x.y.zip }}}
-   <!> Make sure that all files and directories have permissions that makes them accessible
on the web! Note that you will not be able to verify this in a web browser until the new directories
and files have been rsynced to real webserver.
-   <!> Make sure that the owning group is "db". You may need to issue this command:
"chown -R yourName:db x.y".
-  1. Create a page for the release, build/update site
-   {i} For instructions on how to build the website using Forrest, please see: [[http://db.apache.org/derby/papers/derby_web.html]]
-   a. Create an HTML file for the release. 
-    (!) It is a good idea to use the previous release pages as templates, filling in the
changed details as necessary. 
-    {{{
- cd src/documentation/content/xdocs/releases
- cp release-x'.y'.z'.w'.html release-x.y.z.w.html
- vi release-x.y.z.w.html
- }}}
-    <!> 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).
-     * Use search-and-replace to change all occurences of the old version number to the new
-     * Replace the old release notes section with the appropriate fragment from `RELEASE_NOTES.html`
in the new release.
-     * Remove all square brackets [] from the release notes page. When the cgi machinery
sees square brackets, it truncates the release page. (Should be handled by the ReleaseNote
vetter?) In addition, remove all of the blockquote tags; Forrest swallows everything bracketed
by blockquotes. In addition, remove the table of contents (the table of links to anchors in
the release notes); Forrest generates its own table of contents, which is sufficient; if you
leave the original table in the release notes, Forrest will transform it into a list of dead
links. Also remove the mini table of contents in the Issues section. Forrest will munge it
for the same reason.
-     * The boilerplate at the beginning of the release page contains a link to verification
instructions at the end of the page. Make sure that you include the verification boilerplate
at the end so that the link works.
-     * Remove all internal links from the release notes (links to anchors inside the page
itself). Forrest removes your anchors and insists on creating its own anchors using an id
-   a. 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-x.y.z.w.html"/>` (with
the correct version for your release).
-   a. Add a mirroring CGI script for the release. The CGI file should have the same name
as the HTML file, but obviously a `.cgi` extension.
-    (!) The easiest thing is probably just to copy the CGI script for an existing release.

-    * 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`, as described below, before building.
-    * Make sure that the CGI script is made executable by setting `svn:executable` on it

-    {{{
- cd src/documentation/content/xdocs/releases 
- cp release-x'.y'.z'.w'.cgi release-x.y.z.w.cgi
- svn add release-x.y.z.w.cgi      
- svn propset svn:executable ON release-x.y.z.w.cgi }}}
-    <!> Be sure to set `svn:executable` also for the generated copy which forrest builds
into `build/site/releases`.
-   a. Remove mirroring for older releases which no longer require it. 
-    * Svn delete the CGI script. <!> Make sure you do this both in `src/documentation/content/xdocs/releases`
and `build/site/releases`. 
-    * Edit the release page to remove the CGI boilerplate and convert the distribution links
from mirror references to ordinary links. This means replacing the [preferred] tags with the
URL of the archive, i.e. `http://archive.apache.org/dist/`. 
-    (!) To see what the release page should look like, look at the release page for an even
older release.
-    {{{
- cd build/site/releases
- svn delete release-x'.y'.z'.w'.cgi
- cd -
- cd src/documentation/content/xdocs/releases
- svn delete release-x'.y'.z'.w'.cgi
- vi release-x'.y'.z'.w'.html }}}
-   a. Update `src/documentation/content/xdocs/derby_downloads.xml`:
-     * Add a link to the CGI script for the new release at the top of the releases section.
-     * Move the previous release down to the other old releases.
-     * Change the link from the CGI script to the HTML file for all releases for which you
disabled mirroring (in the previous step).
-   a. Update `src/documentation/content/xdocs/papers/DerbyTut/install_software.xml`:
-     * Replace references to the old release number with the new release number.
-   a. Update  `src/documentation/content/xdocs/manuals/index.xml`:
-     * Add the link to the version's manuals (which you uploaded in the previous step).
-     {X} Before checking in changes to the build/site/manuals/index.html, be careful to check
for changes to other areas than those actually modified - especially the japanese characters;
some builds may garble this.
-   a. Run 'forrest site' at the top of the site tree.
-    {i} [[http://db.apache.org/derby/papers/derby_web.html|Forrest instructions]]
-    {X} 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. 
-    {X} The build process frequently will create "false modifications" in `build/tmp` or
`build/site/skin`. These must be reverted before checking in the changes. Subversion may report
some files as changed which should be static. Revert anything in build/site/skin or .png files
under build/site/papers before committing your website changes ([[http://db.apache.org/derby/papers/derby_web.html#odd_diffs|see
the explanation]]).
-    <!> Remember to svn add the new files and set `svn:executable` on the new CGI script
in `build/site/releases` after running forrest!
-    {{{
- rm -rf $FORREST_HOME/main/site/*  # Remove any files from a previous build
- forrest site
- cp -r $FORREST_HOME/main/site build/site
- svn revert -R build/tmp build/site/skin
- svn add build/site/releases/release-x.y.z.w.html
- svn add build/site/releases/release-x.y.z.w.cgi
- svn propset svn:executable ON build/site/releases/release-x.y.z.w.cgi
- }}}
-   a. Check the changes. If they look good, 'svn commit' them.
-   a. Update the website on `people.apache.org`:
-    {{{
- ssh you@people.apache.org
- 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 new release appears on the [[http://db.apache.org/derby/derby_downloads.html|download
page]]. Also check you still can download any release for which you disabled mirroring. Finally
check that you can access the new documentation at the [[http://db.apache.org/derby/manuals/index.html|documentation
-    <!> 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!
-   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.
-   The detailed instructions for deploying Maven 2 artifacts to the Maven repositories are
located in the Derby source tree as `maven2/README.txt`.
-   Below is a brief overview of the process.
-   a. If you do not already have the latest Maven 2 distribution, [[http://maven.apache.org/download.html|download
it]], unpack it, and put the bin directory into your path so that you can run Maven commands.
You also need GnuPG and ssh/scp.
-    {i} As of this writing, the latest 2.x version of Maven was 2.2.1.
-   a. Make sure you can log into people at apache dot org without specifying a password.
This means you have to configure SSH to use key-based authentication. Also make sure that
SSH picks up your Apache user name (action is required if your local account name is different
from you Apache account name).
-   a. Make sure you have your private GPG key and passphrase available. It is recommended
to make the passphrase available to Maven by using an agent, but alternatively you can specify
it on the command line.
-   a. `cd` into Derby's `maven2` directory.
-   a. Compile and run `SetDerbyVersion`.
-   a. Verify the diff (from the `maven2`-directory).
-   a. Run `mvn clean install`
-    {i} This does not build Derby using Maven, it works by copying the pre-built jars.
-   a. Verify the jars installed into your local Maven repository (i.e. `~/.m2/repository/org/apache/derby`).
-   a. Deploy the artifacts to the Apache staging repository: `mvn deploy`
-   a. Verify the group ownership and permissions on the deployed artifacts. In general it
is nice to grant write access to other members of the community, but not to the world!
-   a. Revert local modifications in the `maven2` directory.
-   a. After some time :
-      1. Verify that the artifacts have propagated to the Maven repositories. For 10.6, artifacts
appeared within a day at http://repo1.maven.org/maven2/org/apache/derby/ . It took 6 days
for the artifacts to appear on the external aggregator site ( http://mvnrepository.com/artifact/org.apache.derby
-      1. Add the release to the release history in `maven2/README.txt`.
-  1. Update the release section in the Derby project DOAP file for an official release.
-   {{{
- cd site-trunk
- vi doap_Derby.rdf
- svn commit}}}
-   {i} This DOAP file is the source for http://projects.apache.org/projects/derby.html .
Projects are supposed to get updated periodically (you don't do anything to publish the update).

-   {X} If the update doesn't get generated within a day or two, send email to derby-dev@db.apache.org
letting them know you updated the file and that the update appears to be delayed (site-dev@apache.org
needs to be notified). If you have to post to site-dev@apache.org, make sure that you are
subscribed to that list--your question will be answered there and you won't be able to look
it up later because that list is not archived publicly.
-  1. Announce the release.
-   Twenty-four hours after putting the release files in the mirror directory, verify that
you can reach them through a mirror (the mirroring will likely take effect long before this).
Then, you should email derby-dev, derby-user, general@db.apache.org, announce@apache.org and
anyone else you think might be interested an announcement concerning the release. See past
release announcements for examples.
-   <!> Note that you can only send emails to announce@apache.org from your Apache account!
-   Include a description of the project, and a description of any significant new features
or important bug fixes. 
-   (!) Every tech news blog remotely related to Java or databases will pick up the announcement
and post it verbatim, so it's a good idea to spell check it, proofread it a couple of times,
and/or get input from derby-dev on its content.
-  1. Tag the release in subversion.
-   {{{
- svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/code/branches/{version}/ https://svn.apache.org/repos/asf/db/derby/code/tags/{version}/
- svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/docs/branches/{version}/ https://svn.apache.org/repos/asf/db/derby/docs/tags/{version}/}}}
-  1. Check in a copy of the jars to the jars directory of the repository.
-   Copies of the released jars are kept in the repository for use with the upgrade tests.
You can check in the new jars without having to checkout all of the old jars. First, make
a non-recursive checkout of the jars directory:
-   {{{svn co -N https://svn.apache.org/repos/asf/db/derby/jars/}}}
-   Then create a new directory in the checkout with the version number, copy all of the jar
files into the directory, remove non-Derby jars (like the jakarta jar), then svn add the new
directory and check the directory in.
-  1. Wire the new release into the upgrade tests.
-   Add the new release to the OLD_VERSIONS table in org.apache.derbyTesting.functionTests.tests.upgradeTests.!OldVersions.

-  1. Update the News section of the website.
-   Update the News section at the bottom of the front page of the Derby website. Add the
announcement mail to the top of the news items at http://db.apache.org/derby/index.html#News

-  1. Update wiki Front Page
-   Update any information about new and upcoming releases (for new releases link to the download
page) on the wiki's FrontPage.
-  1. Update JIRA versions and merge development versions into released version.
-   a. Mark the release id as a released version in JIRA.
-    * Go to the Administration page, select Derby, then click the Manage versions link on
the bottom right. 
-    * Click the Release link next to the version id of the release and add the release date.
In addition, you may need to create a new version id for the next release vehicle on the branch.

-   a. The older development versions used for tracking changes between releases are no longer
needed, and old versions should be merged into the release version. E.g. for the
release,,,,, and need to be merged into the released
-    * Click the Merge button next to the oldest release. 
-    * Select all the versions in the list on the right to merge and then the released version
to merge to on the left (in the example above, this would be
-    * Click the Merge button and confirm the merge.
-  1. Update STATUS again.
-   Update STATUS to reflect that the release has occurred. Check in the new file. 
- You're done!
  = Snapshots and Quick Builds =

View raw message