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 2010/04/26 16:46:07 UTC
[Db-derby Wiki] Update of "DerbySnapshotOrRelease" by KristianWaagan
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 KristianWaagan.
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease?action=diff&rev1=145&rev2=146
--------------------------------------------------
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 (NOTE: See how long it takes for the 10.6 release):
+ 1. Verify that the artifacts have been propagated to the Maven repositories.
+ 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).
+
+ 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 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
+ * 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 =
+
+ In essence a snapshot differs from a full release (feature, or bug fix release) in the following ways:
+
+ 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.
+
+ 1. You don't have to polish the release notes for snapshots.
+
+ 1. 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.
+
+ 1. Snapshots don't necessarily include everything included in a full release, for example demos, plugins etc.
+
+ 1. Snapshots are placed in a different location:
+
+ 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.
+
+
+ = Making a (private) Quick Build of Release Artifacts =
+
+ Sometimes it is useful for a Derby developer to build a private version of the release artifacts (archives), for example to verify modifications made to the structure of a specific release distribution (-bin, -lib, -lib-debug, -src, etc.).
+
+ For example, when adding a new demo or changing which files gets included in certain subdirectories of a -bin distribution, reviewing generated release artifacts is often the only way to verify that modifications made to the build scripts are correct (of course, having a developer with knowledge of the build scripts and experience with the release building process review the patch thoroughly would help as well).
+
+ Note that this section describes only a small subset of the steps needed to build a real Apache Derby release. The generated artifacts are '''''suitable for private testing purposes only'''''.
+ * the development community has not been involved
+ * version numbers are probably incorrect
+ * release notes are wrong, or not included at all
+ * jars are not signed
+ * etc. etc.
+
+ To build a set of release artifacts that is suitable for reviewing the file structure of a release, among other things, do the following steps (extracted from the full release procedure description above):
+
+ 1. Check out (or update) the source tree from which you want to build release artifacts, for example
+ https://svn.apache.org/repos/asf/db/derby/code/trunk/ for the trunk
+
+ 1. Make sure you are able to build the code jars the regular way, as described in [[http://svn.apache.org/repos/asf/db/derby/code/trunk/BUILDING.html|BUILDING.html]]
+
+ 1. Check out (or update) the corresponding documentation tree, for example
+ https://svn.apache.org/repos/asf/db/derby/docs/trunk/ for trunk
+
+ 1. Build the documentation (all) as described on the [[http://db.apache.org/derby/manuals/dita.html|web site]]
+
+ 1. Copy ''tools/ant/properties/packaging.tmpl'' to ''tools/ant/properties/packaging.properties'' and modify as necessary (see details above). The important thing here is to include a pointer to you doc build, for example:
+ {{{
+ docs.out=/export/home/tmp/user/docTrunk/trunk/out
+ }}}
+
+ 1. Include the following in your ''ant.properties'' file (for 10.3 or newer), modified to suit your environment:
+ {{{
+ j14lib=/usr/local/java/jdk1.4/jre/lib
+ # For 10.4 or newer:
+ j15lib=/usr/local/java/jdk1.5/jre/lib
+ # For JDBC 4 support
+ jdk16=/usr/local/java/jdk1.6.0
+ # If you want Java ME-support:
+ jsr169compile.classpath=/home/user/lib/cdc/jsr169.jar:/home/user/lib/cdc/btclasses.zip
+ # May not be necessary (?):
+ relnotes.src.reports=/home/user/derby/relnotes-reports # empty directory
+ }}}
+
+ 1. Ensure that 'sane=true' and 'debug=true' are not present in your ''ant.properties'', by removing or commenting out those lines if present.
+
+ 1. In the top-level directory of the source code tree, do:
+ {{{
+ ant prepareforrelease
+ cd tools/release
+ ant release
+ }}}
+
+ ''prepareforrelease'' will actually do:
+ {{{
+ # clean up classes, jars and javadoc:
+ rm -rf jars javadoc snapshot # clean.
+ rm -rf tools/release/crlf/ tools/release/lf/ # clean more.
+ rm tools/release/maintversion.properties # really clean.
+ rm tools/release/*.zip tools/release/*.tar.gz # really,
+ rm tools/release/*.md5 tools/release/*.asc # really clean
+ ant clobber
+ ant sane ; ant all ; ant buildjars # for lib-debug
+ ant clobber
+ ant insane
+ ant -Dsane=false snapshot
+ }}}
+
+ The release artifacts should now be available as ''.zip'' and ''.tar.gz'' files in the ''tools/release/'' directory.
+
+ To clean up, run ''svn stat'' to see which files don't naturally belong in the repository.
+
+
+ = Deprecated instructions =
+
+
+ 1. Deploy to Maven repository.
a. If you do not already have the latest Maven 1 distribution, [[http://maven.apache.org/maven-1.x/start/download.html|download it]], unpack it, and put the bin directory into your path so that you can run maven commands.
{i} As of this writing, the latest 1.x version of Maven was 1.1.
@@ -728, +920 @@
a. Use sftp to bulk put the artifacts into the corresponding subdirectories of `www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/`. Note that there are 3 directories of files (jars, poms, wars) which must be sftp'd from your machine to the tree on people.apache.org.
- 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).
-
- 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 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
- * 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 =
-
- In essence a snapshot differs from a full release (feature, or bug fix release) in the following ways:
-
- 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.
-
- 1. You don't have to polish the release notes for snapshots.
-
- 1. 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.
-
- 1. Snapshots don't necessarily include everything included in a full release, for example demos, plugins etc.
-
- 1. Snapshots are placed in a different location:
-
- 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.
-
-
- = Making a (private) Quick Build of Release Artifacts =
-
- Sometimes it is useful for a Derby developer to build a private version of the release artifacts (archives), for example to verify modifications made to the structure of a specific release distribution (-bin, -lib, -lib-debug, -src, etc.).
-
- For example, when adding a new demo or changing which files gets included in certain subdirectories of a -bin distribution, reviewing generated release artifacts is often the only way to verify that modifications made to the build scripts are correct (of course, having a developer with knowledge of the build scripts and experience with the release building process review the patch thoroughly would help as well).
-
- Note that this section describes only a small subset of the steps needed to build a real Apache Derby release. The generated artifacts are '''''suitable for private testing purposes only'''''.
- * the development community has not been involved
- * version numbers are probably incorrect
- * release notes are wrong, or not included at all
- * jars are not signed
- * etc. etc.
-
- To build a set of release artifacts that is suitable for reviewing the file structure of a release, among other things, do the following steps (extracted from the full release procedure description above):
-
- 1. Check out (or update) the source tree from which you want to build release artifacts, for example
- https://svn.apache.org/repos/asf/db/derby/code/trunk/ for the trunk
-
- 1. Make sure you are able to build the code jars the regular way, as described in [[http://svn.apache.org/repos/asf/db/derby/code/trunk/BUILDING.html|BUILDING.html]]
-
- 1. Check out (or update) the corresponding documentation tree, for example
- https://svn.apache.org/repos/asf/db/derby/docs/trunk/ for trunk
-
- 1. Build the documentation (all) as described on the [[http://db.apache.org/derby/manuals/dita.html|web site]]
-
- 1. Copy ''tools/ant/properties/packaging.tmpl'' to ''tools/ant/properties/packaging.properties'' and modify as necessary (see details above). The important thing here is to include a pointer to you doc build, for example:
- {{{
- docs.out=/export/home/tmp/user/docTrunk/trunk/out
- }}}
-
- 1. Include the following in your ''ant.properties'' file (for 10.3 or newer), modified to suit your environment:
- {{{
- j14lib=/usr/local/java/jdk1.4/jre/lib
- # For 10.4 or newer:
- j15lib=/usr/local/java/jdk1.5/jre/lib
- # For JDBC 4 support
- jdk16=/usr/local/java/jdk1.6.0
- # If you want Java ME-support:
- jsr169compile.classpath=/home/user/lib/cdc/jsr169.jar:/home/user/lib/cdc/btclasses.zip
- # May not be necessary (?):
- relnotes.src.reports=/home/user/derby/relnotes-reports # empty directory
- }}}
-
- 1. Ensure that 'sane=true' and 'debug=true' are not present in your ''ant.properties'', by removing or commenting out those lines if present.
-
- 1. In the top-level directory of the source code tree, do:
- {{{
- ant prepareforrelease
- cd tools/release
- ant release
- }}}
-
- ''prepareforrelease'' will actually do:
- {{{
- # clean up classes, jars and javadoc:
- rm -rf jars javadoc snapshot # clean.
- rm -rf tools/release/crlf/ tools/release/lf/ # clean more.
- rm tools/release/maintversion.properties # really clean.
- rm tools/release/*.zip tools/release/*.tar.gz # really,
- rm tools/release/*.md5 tools/release/*.asc # really clean
- ant clobber
- ant sane ; ant all ; ant buildjars # for lib-debug
- ant clobber
- ant insane
- ant -Dsane=false snapshot
- }}}
-
- The release artifacts should now be available as ''.zip'' and ''.tar.gz'' files in the ''tools/release/'' directory.
-
- To clean up, run ''svn stat'' to see which files don't naturally belong in the repository.
-