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 "TmpDerbySnapshotOrRelease" by MyrnavanLunteren
Date Sun, 07 Oct 2007 19:47:09 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 MyrnavanLunteren:
http://wiki.apache.org/db-derby/TmpDerbySnapshotOrRelease

The comment on the change is:
taking another attempt at DERBY-2575

------------------------------------------------------------------------------
  Temporary wiki page to work on Restructuring the instructions - see DERBY-2575.
  
  '''Table of Contents'''
- [[TableOfContents(3)]]
+ [[TableOfContents(4)]]
  
- == Releases ==
+ = Releases =
  
  
- === high level time line ===
+ == high level time line ==
  once before release:
-   * volunteer for release manager
+   * volunteer for release manager and announce this
    * create wiki pages (main, buddytesting, platform testing, app testing) for release
+   * troll for buddies for buddytesting
    * (optional:) create branch
-   * ensure you have all required tools and files
+   * ensure you have all required tools and files. 
-   * ensure your KEYS are in place, and signed
+   * ensure your KEYS are in place, and signed.
    * create packaging.properties based on packaging.tmpl
-   * create buddytesting page and troll for buddies 
  for each release candidate:
-   * ensure all new files have correct copyright & license
+   * drive bug list to zero
+   * add new section to testing wiki pages
    * arrange for appropriate version numbers in JIRA
+   * ensure all new (and old) files have correct copyright & license
    * svn update source and doc trees
+   * build all, then: 
-   * add new section to testing wiki pages
-   * drive bug list to zero
    * update release.properties
    * create maintversion.properties
    * update masters (ant regex) and test
    * ensure all release notes are current
    * copy rrefexcept.dita from <source>/classes/doc to <docsource>/src/ref
    * update releaseSummary.xml, create release notes & changes files
-   * clean doc & source trees, build release artifacts
+   * clean doc & source trees, then build release artifacts.
    * (optional:) build eclipse plugin
    * sign and place on people.apache.org web site
    * verify a downloaded lib, bin and src distribution (build in the src distribution, preferably
create a release). 
@@ -43, +44 @@

    * update STATUS file
    * deploy to maven repository
  
- === communicate with the community ===
+ == release process steps details ==
  
- The following are the communication tasks the release manager has to take care of:
+ === Before a candidate can be generated ===
+ 
+ ==== Prepare the community for a new release ====
  
   1. Announce your intention/desire to have a release on the list
  
@@ -53, +56 @@

  
   1. Volunteer as release manager (or try to enlist one)
  
-   Since only committers have the necessary access to Apache resources to shepherd a release
to its completion, a committer must volunteer to be the release manager. Usually (hopefully)
someone will volunteer if it is clear there is demand for a release. A release manager is
under no obligation to finish once they volunteer, and another committer can pick up and complete
their work, or even produce a competing release if so desired.
+   Since only committers have the necessary access to Apache resources to shephard a release
to its completion, a committer must volunteer to be the release manager. Usually (hopefully)
someone will volunteer if it is clear there is demand for a release. A release manager is
under no obligation to finish once they volunteer, and another committer can pick up and complete
their work, or even produce a competing release if so desired.
  
+  1. For major releases, create a new branch for the release, in both the code and docs trees.
+ 
+   {{{svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/code/trunk/ https://svn.apache.org/repos/asf/db/derby/code/branches/{branchname}/
+ svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/docs/trunk/ https://svn.apache.org/repos/asf/db/derby/docs/branches/{branchname}/}}}
+ 
+   After creating the branch, bump the version number on the trunk. There is not currently
an ant target for bumping the version number on the trunk. You should edit tools/ant/release.properties
on trunk by hand to bump the major/minor properties as appropriate, zero out the maint property,
and ensure the beta flag is set to true. Then, from the top, run:
+   {{{java org.apache.derbyBuild.maintversion2props tools/ant/properties/release.properties
tools/release/maintversion.properties}}}
+   {{{cd tools/release
+ ant regex.masters}}}
+   Note: the regex.masters target does not currently account for changes in the beta flag.
Run the tests to make sure  the output files are correct. Don't forget to post to derby-dev
requesting that a new version be added to JIRA for the next version of Derby.
+ 
+   Add the new branch number to the list of Branches on the source page of the website. For
instructions on how to build the website using Forrest, please see: [http://db.apache.org/derby/papers/derby_web.html]
+  The actual page to modify is src\documentation\content\xdocs\dev\derby_source.xml.
+ 
+   For a minor (bug fix) release, consider bumping the third version of the source tree it
will come off (likely a branch).
+ 
-  1. Make a wiki page for the release. 
+  1. Create wiki pages for the release.
  
-   On it, identify timeframes, and let the community identify items for special mention (or
do this yourself). Also prepare a place to gather testing information (for instance, use a
previous' release's wiki pages as a starting point).
+   Use pages for a previous release as a template. You're likely to create a general page
and a page to hold the testing information.
  
-  1. Arrange for appropriate version numbers in JIRA
+ ==== Work the toward a release candidate ====
  
+  1. Arrange for the version in JIRA; See section titled 'JIRA version maintenance'.
-   The JIRA administrators will need to do this. This is a little more tricky than it seems;
You have to decide what the release is going to be called, and it ties in with the technical
part of where the release info is coming from in the code (essentially, <branch/trunk>/tools/ant/properties/release.properties).
Note, if you need to make a branch, that the first release off the branch will report 'beta',
no matter what the 'beta' flag in release.properties says. A release candidate should not
have the 'beta' flag.
- 
-  1. Drive the bug list to zero
- 
-   Communicate with the community about which bugs need to get fixed, which bugs need release
notes, and what else needs to be in the release notes. 
- 
-  1. Address items on the ReleaseVettingChecklist
- 
-   Make sure that the community addresses relevant items on the ReleaseVettingChecklist.
- 
-  1. Vote on the distributions
- 
-   Call for a vote on derby-dev to have the distributions posted on your public_html accepted
for the release. A vote needs to be running for at least 7 days, so, give at least that much
time before closing the vote to give adequate time for others to inspect and test the distributions.
If no-one has responded after a week, prod gently until you get a response. A majority of
votes, and at least three binding +1 vote are required for acceptance.
- 
-   Forward or bcc a copy of the call for vote to private@db.apache.org so the DB PMC is aware
that a vote is in progress. Also forward the results post to private@db.apache.org. (Note:
do not '''cc''' the PMC; '''bcc''' or forward a copy of the post.)
- 
-  1. If vote does not pass 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.
- 
- 
- 
- === herding bugs, changes, fixes, release notes ===
- 
- The release manager needs to do the following tasks with JIRA:
  
   1. 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
-   Mark the Fix In field for the JIRA entries for the items you (and/or the community) want
to be in the release with the proper version. Also, it's a good idea to post to derby-dev
to get an idea of what features or fixes other contributors would like in the release.
+   Mark the Fix In field for the JIRA entries for the items you want to be in the release
with the proper version. Also, it's a good idea to post to derby-dev to get an idea of what
features or fixes other contributors would like in the release.
  
   1. Fix the bugs, update STATUS and CHANGES/RELEASE_NOTES.html as needed
  
-   Get to work! Add features, fix bugs, and update STATUS as you go. The wiki is nice, as
are personal webpages, but STATUS is the designated place for Apache projects to keep their
current status. Apache members and committers expect to be able to grab the STATUS file from
the code tree to determine the current status of the project. It's a nice thing to keep the
STATUS file on branches up to date with the current status of the branch. The other essential
document is a document describing the changes. Derby branches up to 10.2 included a file 'CHANGES'
for that purpose; 10.3 branch and trunk have a RELEASE_NOTES.html checked in, as well as CHANGES.html.
RELEASE_NOTES.html is generated using the generator in <10.3 branch and /trunk>/java/build/org/apache/derbyBuild/ReleaseNotesGenerator.java,
which is activated by executing ant genrelnotes in tools/release. The CHANGES.html file can
be generated using <10.3 branch and /trunk>/java/build/org/apache/derbyBuild/ChangesFileGener
 ator.java, which can be activated using ant genchanges in tools/release.
+   Get to work! Add features, fix bugs, and update STATUS as you go. The wiki is nice, as
are personal webpages, but STATUS is the designated place for Apache projects to keep their
current status. Apache members and committers expect to be able to grab the STATUS file from
the code tree to determine the current status of the project. It's a nice thing to keep the
STATUS file on branches up to date with the current status of the branch. The other essential
document is a document describing the changes. Derby branches up to 10.2 included a file 'CHANGES'
for that purpose; 10.3 branch and trunk have a RELEASE_NOTES.html checked in. RELEASE_NOTES.html
is generated using the generator in <10.3 branch and up/trunk>/java/build/org/apache/derbyBuild/ReleaseNotesGenerator.java,
which is activated by executing ant genrelnotes in tools/release. The CHANGES.html file can
be generated using <10.3 branch and /trunk>/java/build/org/apache/derbyBuild/ChangesFileGenerator.java,
which can be
  activated using ant genchanges in tools/release.
  
   1. Drive the bug list to zero.
  
@@ -106, +101 @@

      * fixed in the release under study but not in the previous release
      * marked with 'Existing Application Impact' or 'Release Note Needed'.
  
- 
- === prepare the source for building the release ===
- 
-  1. For major releases, create a new branch for the release, in both the code and docs trees.
- 
-   {{{svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/code/trunk/ https://svn.apache.org/repos/asf/db/derby/code/branches/{branchname}/
- svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/docs/trunk/ https://svn.apache.org/repos/asf/db/derby/docs/branches/{branchname}/}}}
- 
-   After creating the branch, bump the version number on the trunk. There is not currently
an ant target for bumping the version number on the trunk. You should edit release.properties
on trunk by hand to bump the major/minor properties as appropriate, zero out the maint property,
and ensure the beta flag is set to true. Then, from the top, run:
- 
-   {{{java org.apache.derbyBuild.maintversion2props tools/ant/properties/release.properties
tools/release/maintversion.properties}}}
-   {{{cd tools/release
- ant regex.masters}}}
- 
-   Add the new branch number to the list of Branches on the source page of the website. For
pointers on how to edit the downloads page, see the "Update the website" section below in
the Snapshot instructions. The actual page to modify is src\documentation\content\xdocs\dev\derby_source.xml.
-   Note: the regex.masters target does not currently account for changes in the beta flag.
Run the tests to make sure the output files are correct. Don't forget to post to derby-dev
requesting that a new version be added to JIRA for the next version of Derby.
- 
-  1. Make sure your public PGP/GPG key is in the KEYS file
- 
-   For information about PGP and why it is used to sign release binaries at Apache, please
read [http://people.apache.org/~henkp/trust/].
- 
-   You should create a PGP key for yourself if you do not have one, and upload it to at least
one, preferably two, of the main public keyservers, e.g. pgp.mit.edu. You will need this key
to sign the release binaries. Your key should be tied into the Apache web of trust, which
means you should have at least one person sign your key, and you should have done gpg --refresh-keys
to get that person's signature before you follow the steps at the top of the KEYS file.
- 
-   GPG is available for a variety of platforms from http://gnupg.org. PGP is a commercial
product which is available from http://pgp.com.
- 
-   Your KEY needs to be in the KEYS file in trunk, KEYS file on the branch if you've created
one, and the KEYS file in /www/www.apache.org/dist/db/derby at people.apache.org.
- 
-  1. Check that all creative works have ASF license headers. See: [http://wiki.apache.org/db-derby/FixingLicenseHeader].

+  1. Check that all creative works have ASF license headers. See: [http://wiki.apache.org/db-derby/FixingLicenseHeader].
+ 
+  1. Check that the year and other information is correct.
+ 
-   Also ensure that the year in NOTICE is correct. Similarly, ensure that all versions and
copyright details in the docs tree are correct, this includes the top level conrefs.dita,
as well as lower level dita files.
+   Ensure that the year in NOTICE is correct. Ensure that all versions and copyright details
in the docs tree are correct, this includes the top level conrefs.dita, as well as lower level
dita files.
  
- === prepare for the release management task ===
+ ==== Environment requirements for the release manager ====
  
  To be able to produce the release artifacts, you need to
    * update version numbers and run tests to verify it was correct
@@ -144, +115 @@

    * build all in doc and source objects (except for eclipse ui and doc plugins, those are
optional)
    * sign 
    * verify
+ and after the release has been voted on:
    * modify derby web
    * distribute to maven
  
@@ -172, +144 @@

  relnotes.src.reports=<location where you want to save/access the xml scripts for generating
release notes>
  #sane=<sane should *not* be set>}}}
  
- 
  special consideration for windows users:
    * ant sign, the last step in the ant release process, may not work. 
    try it out before the release time is there; if you cannot do this, you may achieve the
same using  the following script 
    * similarly, you may use a script to verify the release
    * your md5 tool may be different.
    you'll need to copy the file packaging.tmpl to packaging.properties and adjust it appropriately.
-   
- === prepare your machine/environment for building the release artifacts ===
  
+ ==== Steps to prepare your machine/code check-out for the release process ====
+ 
+  1. Get a clean copy of the source tree for your version
+ 
+   A clean check-out is best.
+ 
+  1. Obtain files for building all optional pieces:
+   Consult BUILDING.txt and make sure you have all relevant pieces not in the source tree:
+   * jdk14
+   * jdk15 (after 10.3.*)
+   * jdk16
+   * junit.jar 
+  including those required for building the optional pieces:
+   * The jdk1.6-specific classes (JDBC4 support)
+   * The OSGi support
+   * The JSR169 support
+ 
+  1. Copy tools/ant/properties/packaging.tmpl to tools/ant/properties/packaging.properties
and modify as necessary.
+ 
+   The build will attempt to use a file called tools/ant/properties/packaging.properties
to carry out checksum (md5)and signing (pgp) tasks. Because this differs per operating system,
you have to create this file based on the template (tools/ant/properties/packaging.tmpl) which
is set for a likely linux environment.  
+ 
+   Most Unix distributions come with either md5 or md5sum. An md5sum utility for Windows
can be downloaded as a part of the !GnuWin32 port of the core Gnu utilities, from: http://gnuwin32.sourceforge.net/packages/coreutils.htm.
A standalone md5 utility can be found at http://www.fourmilab.ch/md5/. Note, for the executable
available from this last location, the correct option for output is md5 -n.
+ 
+   For pgp look on below...
+ 
+  1. Make sure your public PGP/GPG key is in the KEYS file, and preferably after it has been
signed.
+ 
+   For information about PGP and why it is used to sign release binaries at Apache, please
read [http://people.apache.org/~henkp/trust/].
+ 
+   You should create a PGP key for yourself if you do not have one, and upload it to at least
one, preferably two, of the main public keyservers, e.g. pgp.mit.edu. You will need this key
to sign the release binaries. Your key should be tied into the Apache web of trust, which
means you should have at least one person sign your key, and you should have done gpg --refresh-keys
to get that person's signature before you follow the steps at the top of the KEYS file.
+ 
+   GPG is available for a variety of platforms from http://gnupg.org. PGP is a commercial
product which is available from http://pgp.com.
+ 
+   Your KEY needs to be in the KEYS file in trunk, KEYS file on the branch if you've created
one, and the KEYS file in /www/www.apache.org/dist/db/derby at people.apache.org.
+  
+   You need to make sure the tools/ant/properties/packaging.properties file has correct information
for your pgp tool.
+ 
+  1. Ensure you have appropriate jdks available
+ 
+   See BUILDING.txt for information on JSR169 and OSGI support.
+ 
+   For 10.2 forward, make sure that you have JDK 1.6 available and that you've set the jdk16
property to the JAVA_HOME for your JDK 1.6 installation in your ant.properties so that the
JDBC 4.0 classes are built and the JDBC 4.0 javadoc is created.
+ 
+   For versions after 10.3, you need to also have jdk1.5 available
+ 
+  1. Check out a clean copy of the doc tree
+ 
+   Once you have a copy of the documentation on your local machine, you will need to update
the property ${docs.out} in tools/ant/properties/packaging.properties to point to your local
copy of the documentation. 
+ 
+   To build the documentation, you need to obtain DITA-OT1.1.2.1_bin-ASL.zip and place it
in the docs' tree lib. See: [http://db.apache.org/derby/manuals/dita.html] for more info about
building the documentation.
+ 
+ === For each release candidate ===
+ 
+ ==== Check-ins just before generating release artifacts ====
+ 
-  1. Bump the third version number, adjust the beta flag, finalize CHANGES, and RELEASE-NOTES
and check in the new version and test masters. 
+  1. Bump the version number, adjust the beta flag 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:
+   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.

+   Note: the regex.masters target does not currently account for changes in the beta flag.

+ 
+   You will need to clobber and build again 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.
+ 
+   It's a good idea to build, then run at least one of the affected tests to make sure they
pass, before checking in the changed masters.
  
   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].
  
+  1. finalize CHANGES. This can include items in addition to the RELEASE_NOTES, which are
purely for user purposes. 
+   The tool java/tools/ChangesFileGenerator.java can help you generate this file; it works
similar to the ReleaseNotesGenerater.
+ 
+  1. Check in the latest SQLState documentation.
+ 
+   Build the source tree. The SQLStates are documented in the Reference Guide on the following
page: rrefexcept71493.dita. This file is generated by the Derby build and placed in classes/doc.
Take the version of this file generated by building the code branch and check it into the
doc branch at src/ref/rrefexcept71493.dita.
+ 
-  1. Sync the repository.
+  1. Sync the source and doc repository.
  
    'svn up' in your subversion view to bring all files in your view up to the latest revision.
Otherwise, the version output by svn which is captured for the build number will be a range
(e.g. 290275:320938).
  
-  1. Check in the latest SQLState documentation.
+ ==== Build the release artifacts ====
  
-   The SQLStates are documented in the Reference Guide on the following page: rrefexcept71493.dita.
This file is generated by the Derby build and placed in classes/doc. Take the version of this
file generated by building the code branch and check it into the doc branch at src/ref/rrefexcept71493.dita.
- 
-  1. Make sure you have the doc tree checked out, and a clean copy of the source checkout.
- 
- 
-  1. Make sure your build will build all of the optional components.
- 
-   Consult BUILDING.txt and make sure that your build will compile the optional pieces:
- 
-   * The jdk1.6-specific classes (JDBC4 support)
-   * The OSGi support
-   * The JSR169 support
- 
+  1. Check you have all required pieces:
+ 	- doc tree
+ 	  - with DITA library
+ 	  - with latest SQLState
+ 	- KEYS checked in
+ 	- RELEASE_NOTES and CHANGES checked in
+ 	- md5 & pgp and docs info set correctly in tools/ant/properties/packaging.properties
and available (PATH)
+ 	- generated updated tools/release/maintversion.properties
+ 	- updated masters checked in
+ 	- ant.properties set correctly for:
+ 		osgi.jar, jdk15, jdk16, jsr169
+ 	- sane not set in ant.properties
+ 	- non-source files for building source available: junit.jar, osgi.jar, dita library (again).
+  
   1. Build the documentation.
  
-   The documentation needs to be included in the -bin distribution and src, so you will need
to access the doc branch when running the ant release target. Information on building the
docs is located at [http://db.apache.org/derby/manuals/dita.html]. 
+   The documentation needs to be included in the -bin distribution and src, so you will need
to access the doc branch when running the ant release target. The doc build is not controlled
by the source tree build, and thus needs to be completed beforehand. Information on building
the docs is located at [http://db.apache.org/derby/manuals/dita.html]. 
- 
-  1. Copy packaging.tmpl to packaging.properties in tools/release and modify as necessary.
- 
-   Once you have a copy of the documentation on your local machine, you will need to update
the property ${docs.out} in tools/ant/properties/packaging.properties to point to your local
copy of the documentation. Check that the settings in tools/ant/properties/packaging.properties
are correct for your md5 hash tool and pgp/gpg tool and then go to the next step.
- 
-   Most Unix distributions come with either md5 or md5sum. An md5sum utility for Windows
can be downloaded as a part of the !GnuWin32 port of the core Gnu utilities, from: http://gnuwin32.sourceforge.net/packages/coreutils.htm.
A standalone md5 utility can be found at http://www.fourmilab.ch/md5/. Note for the executable
available from this last location, the correct option for output is md5 -n.
- 
-  1. Create the release distributions and checksums, sign the distributions
- 
-   Check your classpath for osgi.jar for OSGI support and make sure jsr169compile.classpath
is set for J2ME support. 
- 
-   For 10.2 forward, make sure that you have JDK 1.6 available and that you've set the jdk16
property to the JAVA_HOME for your JDK 1.6 installation in your ant.properties so that the
JDBC 4.0 classes are built and the JDBC 4.0 javadoc is created. If you have the sane property
set in your ant.properties, remove it at this time to prevent it from overriding the false
setting passed into the snapshot target.
- 
- === building the release artifacts ===
-  
-  1. ensure you have all required steps (osgi, junit, jdk14, jdk16, jsr169compile.path, sane
*not* set, maintversion.properties correct, masters updated, doc reference set in packaging.properties,
CHANGES.html and RELEASE-NOTES.html updated, docs built correctly)
  
   1. Create the distributions for release by running:
  
@@ -262, +280 @@

     *db-derby-[version]-src.tar.gz
     *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:
+   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 directory), 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:
  
    {{{gpg --armor --detach-sign derby_ui_plugin_[version].zip
  gpg --armor --detach-sign derby_core_plugin_[version].zip
@@ -310, +328 @@

  
    And comparing the output of openssl to the output from ant in db-derby-10.1.1.0-src.zip.md5
  
-  1. Bump the fourth digit of the version
- 
-   See step #4 in the snapshot section.
+  1. Bump the fourth digit of the source in preparation for a possible next build; update
the masters
+   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}}}
  
   1. Post the distributions
  
    Copy the files from tools/release to your public_html directory on people.apache.org.
Post to derby-dev so that  others can begin testing.
  
+  1. Vote on the distributions
  
- === publish new release ===
+   Call for a vote on derby-dev to have the distributions posted on your public_html accepted
for the release. A vote needs to be running for at least 7 days, so, give at least that much
time before closing the vote to give adequate time for others to inspect and test the distributions.
If no-one has responded after a week, prod gently until you get a response. A majority of
votes, and at least one binding +1 vote are required for acceptance.
+ 
+   Forward or bcc a copy of the call for vote to private@db.apache.org so the DB PMC is aware
that a vote is in progress. Also forward the results post to private@db.apache.org. (Note:
do not '''cc''' the PMC; '''bcc''' or forward a copy of the post.)
+ 
+ ==== 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 '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.
+ 
+ === After a successful vote ===
  
   1. If the vote passes, put distributions onto mirrors
  
@@ -354, +391 @@

  
    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.
  
-   You should also make sure that your public PGP key is in the KEYS file at /www/www.apache.org/dist/db/derby/KEYS
  
   1. Create a page for the release, build/update site
  
-   For instructions on how to build the website, see item 3 regarding snapshots below. 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. 
+   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.
+ 
+  b. Run 'forrest site' at the top of the site tree.
+ 
+  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.
+ 
+  d. Update the website on people.apache.org by logging into the machine and doing:
+ 
+  {{{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 (3e above), 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!
  
    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).
@@ -375, +426 @@

    * 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]).
    * 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
  
+ 
   1. Deploy to Maven repository.
  
    First, if you do not already have the latest Maven 1 distribution, download it from http://maven.apache.org/maven-1.x/start/download.html,
unpack it, and put the bin directory into your path so that you can run maven commands. As
of this writing, the latest 1.x version of Maven was 1.0.2.
@@ -444, +496 @@

  
     $ maven multiproject:deploy
  
- 
    This will build the artifacts into a subtree rooted at garbage. Use sftp to bulk put the
artifacts into the corresponding subdirectories of www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/.
- 
  
   1. Update the Derby project DOAP file for an official release.
  
@@ -455, +505 @@

  
     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). 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).
  
+  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. 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.
+ 
+   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/{trunk_or_branchname}/
https://svn.apache.org/repos/asf/db/derby/code/tags/{version}/
+ svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/docs/{trunk_or_branchname}/
https://svn.apache.org/repos/asf/db/derby/docs/tags/{version}/}}}
+ 
+  1. Update STATUS again.
+ 
+   Update STATUS to reflect that the release has occurred. Check in the new file. You're
done!
+ 
+  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 JIRA versions and merge development versions into released version.
+ 
+   Mark the release id as a released version in JIRA. To do this, 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. 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 10.3.1.4 release, 10.3.0.0, 10.3.1.0,
10.3.1.1, 10.3.1.2, and 10.3.1.3 need to be merged into the released 10.3.1.4. 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
10.3.1.4), and click the Merge button and confirm the merge.
  
   1. Announce the release.
  
@@ -483, +555 @@

  
   1. Update JIRA versions and merge development versions into released version.
  
-   Mark the release id as a released version in JIRA. To do this, 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. 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 10.3.1.4 release, 10.3.0.0, 10.3.1.0,
10.3.1.1, 10.3.1.2, and 10.3.1.3 need to be merged into the released 10.3.1.4. 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
10.3.1.4), and click the Merge button and confirm the merge.
- 
  You're done!
  
  
+ 
+ 
- == Snapshots ==
+ = 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.
+ In essence a snapshot differs from a full release (feature, or bug fix release) in the following
ways:
  
-  1.#2 Run the snapshot target.
+ 1. A snapshot is an alpha or beta distribution cut from the trunk, while a release (candidate)
is supposed to be a full-fledged, upgradeable distribution, and likely cut from a branch.

  
-   At the top of your subversion view of the trunk or one of the branches, do:
+ 2. You don't have to polish the release notes for snapshots.
  
+ 3. For snapshots, the vetting cycle is shorter and the community is willing to tolerate
regressions and serious bugs in the interests of garnering early feedback. 
-   {{{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
- ant clobber
- ant insane
- ant -Dsane=false snapshot}}}
  
+ 4. Snapshots are placed in a different location:
-   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
-   * db-derby-snapshot-debug-[version]-[changenumber].tar.gz
-   * db-derby-snapshot-debug-[version]-[changenumber].zip
-   * derby_core_plugin_[version]_[changenumber].zip
- 
-   The need to run 'ant insane' as a separate step before the snapshot is filed in JIRA as
DERBY-744.
- 
-  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]
- 
-  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.
- 
-  c. Run 'forrest site' at the top of the site tree.
- 
-  d. Check the changes. If they look good, 'svn commit' them. NOTE: you should revert any
changed files in build/tmp or build/site/skin. Also, please {{{svn delete}}} any old snapshot
files that are no longer necessary.
- 
-  e. Update the website on people.apache.org by logging into the machine and doing:
- 
-  {{{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
- 
-  1.#4 Bump the version number.
- 
-  In the tools/release directory, run the Ant bumplastdigit target.
- 
-  {{{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.
- 
-  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.
  
-   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.
- 

Mime
View raw message