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 Fri, 27 Jul 2007 06:28:22 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

------------------------------------------------------------------------------
  
   1. Announce your intention/desire to have a release on the list
  
+   As new features are added and bugs fixed, it is likely that someone will announce their
intention to produce a release (if they are a committer) and volunteer to be the release manager.
It may also be the case that a non-committer will ask when the next official release will
occur. This should be a sign to committers that there is demand for a release. :)
-   As new features are added and bugs fixed, it is likely that someone will announce their
intention to produce a 
- 
- release (if they are a committer) and volunteer to be the release manager. It may also be
the case that a non-
- 
- committer will ask when the next official release will occur. This should be a sign to committers
that there is 
- 
- demand for a release. :)
  
   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 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.
  
   1. Make a wiki page 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).
- 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).
  
   1. Arrange for appropriate version numbers in JIRA
  
+ 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.
- 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 
+ 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. 
- 
- needs to be in the release notes. 
  
   1. Address items on the ReleaseVettingChecklist
  
@@ -103, +77 @@

  
   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 
+   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.)
- 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.
-   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.
  
  
  
@@ -132, +94 @@

   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 (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.
  
   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, as well as CHANGES.html. 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. 
  
   1. Drive the bug list to zero.
  
+   As the list of remaining bugs in JIRA approaches zero, be sure to mark their status properly
in JIRA. Mark blocker and critical bugs as such so that others can see the status at a glance.
Move non-showstopper bugs out to future releases if it appears they will not be fixed for
this release.
-   As the list of remaining bugs in JIRA approaches zero, be sure to mark their status properly
in JIRA. Mark blocker 
- 
- and critical bugs as such so that others can see the status at a glance. Move non-showstopper
bugs out to future 
- 
- releases if it appears they will not be fixed for this release.
  
   1. Drive the creation of release notes.
    The release note generator expects files called 'ReleaseNote.html' for each item marked
that is:
@@ -175, +115 @@

  
   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/ 
+   {{{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:
- 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

+   {{{java org.apache.derbyBuild.maintversion2props tools/ant/properties/release.properties
tools/release/maintversion.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.
+   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.
-   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 
+   For information about PGP and why it is used to sign release binaries at Apache, please
read [http://people.apache.org/~henkp/trust/].
  
- [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.
  
-   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 
+   GPG is available for a variety of platforms from http://gnupg.org. PGP is a commercial
product which is available from http://pgp.com.
  
- 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 
+   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].
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.
- 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]. 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.
  
  === prepare for the release management task ===
  
@@ -248, +152 @@

  
  This means you have to have to be able to do the following / use the following tools:
  - md5 
- - pgp (see: )
+ - pgp (see: [http://people.apache.org/~henkp/trust/], [http://gnupg.org] or [http://pgp.com.]
)
  - ant (see BUILDING.txt)
  - dita (see:  )
  - forrest (see:  )
@@ -261, +165 @@

  - junit.jar (see BUILDING.txt)
  - ditazip (see: )
  
- You need to at least have the doc tree and source tree available, and your ant.properties
file needs to
+ You need to at least have the doc tree and source tree available, and your ant.properties
file needs to include:
- include:
  j14lib=<location of jdk14(2)/jre/lib>
  jdk16=<location of jdk16>
  jsr169compile.classpath=<location of jsr169 implementation>
@@ -275, +178 @@

  
  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
+   try it out before the release time is there; if you cannot do this, you may achieve the
same using  the following script
-   the following script
  
  - similarly, you may use a script to verify the release
  
@@ -818, +720 @@

  
  to add a new version in JIRA.
  
- 

Mime
View raw message