You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by Apache Wiki <wi...@apache.org> on 2007/07/27 09:42:04 UTC

[Db-derby Wiki] Trivial Update of "TmpDerbySnapshotOrRelease" by MyrnavanLunteren

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 MyrnavanLunteren:
http://wiki.apache.org/db-derby/TmpDerbySnapshotOrRelease

------------------------------------------------------------------------------
  Temporary wiki page to work on Restructuring the instructions - see DERBY-2575.
+ 
  '''Table of Contents'''
  [[TableOfContents(3)]]
  
@@ -183, +184 @@

  
   1. Bump the third version number, adjust the beta flag, finalize CHANGES, and RELEASE-NOTES and check in the new version and test masters. 
    You will need to clobber and build to before you can see the changed release number(s) reflected in the source. Note that the first release off a new branch is automatically beta, even if you set the beta flag in tools/ant/properties/release.properties to false. Also adjust version numbers in documentation by modifying the appropriate *conrefs.dita files.
+ 
    There is not currently an ant target for bumping the third version number. The third and fourth parts of the version are combined into a single property, maint, where maint = (third digit * 1000000) + fourth digit. Also, if this is a major/minor (feature) release, you should remove the beta flag at this time. You should update tools/ant/properties/release.properties by hand and then run:
- 
    {{{java org.apache.derbyBuild.maintversion2props tools/ant/properties/release.properties tools/release/maintversion.properties
  cd tools/release
  ant regex.masters}}}
  
    TODO: the regex.masters target does not currently account for changes in the beta flag. 
  
-   1. Generate RELEASE_NOTES.html in the branch and check it into the svn repository.
+  1. Generate RELEASE_NOTES.html in the branch and check it into the svn repository.
  
    Please consult the instructions for [http://wiki.apache.org/db-derby/ReleaseNoteProcess generating release notes].
  
@@ -232, +233 @@

  
  === building the release artifacts ===
  
- 1. Create the distributions for release by running:
+  1. Create the distributions for release by running:
  
    {{{svn up
  ant clobber
@@ -250, +251 @@

  
    You will need to enter your PGP passphrase several times as the release distributions are signed. This will create the following files in your tools/release directory:
  
-   *db-derby-[version]-bin.tar.gz
+    *db-derby-[version]-bin.tar.gz
-   *db-derby-[version]-bin.zip
+    *db-derby-[version]-bin.zip
-   *db-derby-[version]-lib.tar.gz
+    *db-derby-[version]-lib.tar.gz
-   *db-derby-[version]-lib.zip
+    *db-derby-[version]-lib.zip
-   *db-derby-[version]-lib-debug.tar.gz
+    *db-derby-[version]-lib-debug.tar.gz
-   *db-derby-[version]-lib-debug.zip
+    *db-derby-[version]-lib-debug.zip
-   *db-derby-[version]-src.tar.gz
+    *db-derby-[version]-src.tar.gz
-   *db-derby-[version]-src.zip
+    *db-derby-[version]-src.zip
  
    The Eclipse core plugin is generated in the snapshot directory at the top level by the snapshot target. You should also create the Eclipse UI plugins (see plugins/eclipse/readme.txt, except use the core plugin created in the snapshot), but this requires Eclipse. If you don't want to do it yourself, those interested in the Eclipse plugins will likely volunteer to generate them for you. You should also create checksums and signatures for these files with:
  
@@ -286, +287 @@

  
    Be sure to replace the commands for gpg and md5 with the correct commands for your system. Note that on cygwin, the md5 switch is "-n" rather than "-q".
  
-   1. Verify the signatures and checksums.
+  1. Verify the signatures and checksums.
  
    As an example, the Derby 10.1 archives would be verified with PGP as follows:
  
@@ -475, +476 @@

  == Snapshots ==
   1. Update CHANGES.
  
-  Edit the CHANGES file to include a list of the bug fixes included in the snapshot. It is not necessary to make an exhaustive list of subversion commits. Only changes that would be visible to a user need to be included.
+   Edit the CHANGES file to include a list of the bug fixes included in the snapshot. It is not necessary to make an exhaustive list of subversion commits. Only changes that would be visible to a user need to be included.
  
   1.#2 Run the snapshot target.
  
-  At the top of your subversion view of the trunk or one of the branches, do:
+   At the top of your subversion view of the trunk or one of the branches, do:
  
-  {{{svn up
+   {{{svn up
  ant clobber
  rm -rf jars javadoc snapshot    # make sure everything is cleaned out
  ant sane ; ant all ; ant buildjars   # for the debug archives
@@ -489, +490 @@

  ant insane
  ant -Dsane=false snapshot}}}
  
-  It is best to do this in a view where there are no modified files or mixed revisions. This will create a snapshot directory at the top level, which will contain the five snapshot files:
+   It is best to do this in a view where there are no modified files or mixed revisions. This will create a snapshot directory at the top level, which will contain the five snapshot files:
  
    * db-derby-snapshot-[version]-[changenumber].tar.gz
    * db-derby-snapshot-[version]-[changenumber].zip
@@ -501, +502 @@

  
   1.#3 Update the website.
  
-  For instructions on how to build the website using Forrest, please see: http://db.apache.org/derby/papers/derby_web.html
+  For instructions on how to build the website using Forrest, please see: [http://db.apache.org/derby/papers/derby_web.html]
  
-   a. Place the five files created by the snapshot target into the src/documentation/content/xdocs/binaries directory of the location to which you checked out the website source. 'svn add' them, and 'svn delete' any old snapshot that the new snapshot is replacing. Don't forget to 'svn add' the files in the build part of the site tree.
+  a. Place the five files created by the snapshot target into the src/documentation/content/xdocs/binaries directory of the location to which you checked out the website source. 'svn add' them, and 'svn delete' any old snapshot that the new snapshot is replacing. Don't forget to 'svn add' the files in the build part of the site tree.
  
   b. Update the derby_downloads.xml page in the src/documentation/content/xdocs directory so that the links to the current snapshot point to your new files.
  
@@ -516, +517 @@

   {{{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
+    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
  
   1.#4 Bump the version number.
  
@@ -525, +526 @@

   {{{cd tools/release
  ant bumplastdigit}}}
  
-  This target updates tools/ant/properties/release.properties and several test canons that contain the version number. Check that the version number is correct. 'svn commit' the changed files.
+   This target updates tools/ant/properties/release.properties and several test canons that contain the version number. Check that the version number is correct. 'svn commit' the changed files.
  
   1.#5 Announce to the lists.
  
-  It's a good idea, once the snapshot has appeared on the site, to announce to derby-dev and derby-user that the new snapshot has been posted so interested testers can grab it.
+   It's a good idea, once the snapshot has appeared on the site, to announce to derby-dev and derby-user that the new snapshot has been posted so interested testers can grab it.
  
-  Also, a new JIRA version will need to be created for the new, bumped version number. An email to derby-dev stating that you've bumped the version will (hopefully) be sufficient to get the attention of one of the Derby JIRA admins to add a new version in JIRA.
+   Also, a new JIRA version will need to be created for the new, bumped version number. An email to derby-dev stating that you've bumped the version will (hopefully) be sufficient to get the attention of one of the Derby JIRA admins to add a new version in JIRA.