This project has retired. For details please refer to its Attic page.
Apache ODE – Release Guidelines
Apache ODE

Release Guidelines

Check List

These guidelines are extracted from the incubator release guidelines and other projects (like Avalon) guidelines and are meant to be used as a reference for coming releases. It's not really a todo list for the next release (that will be handled in JIRA) but a general list of things to have right and the places they're best described.

  • Analyze the list of bugs left for this specific release. Assess whether they're critical for the release or can be postponed to a subsequent release.
  • The released archives should have "apache" and "ode" in their naming.
  • A release should include both a source and a binary package.
  • The source distro should include a BUILDING document.
  • make sure the RELEASE_NOTES are up to date (version number, list of issues, links to JIRA, etc)
  • Both distros should include a RELEASE_NOTES, the LICENSE
  • Different distribution types should unpack to directories with different names (say apache-ode-x.x and apache-ode-src-x.x).
  • Our releases don't include general documentation (only Javadoc) but a link to our website main documentation pages in the README.
  • All our jars must include in the META-INF the LICENSE, the NOTICE, a valid MANIFEST.
  • The NOTICE file must include: the standard Apache attribution and copyright notice, inherited copyright and attributions notices, all attribution and copyright notices required by licenses for third party documents.
  • Releases should be built from tagged versions named APACHE_ODE_X_X (roughly same as the release itself but in capital to mark it different from other tags).
  • All our source files should include the legal Apache header.
  • The Java version should be clearly indicated either in README or RELEASE_NOTES (in addition to the MANIFEST).

Verifying the release

A complete check list.

Release Process

Before the release is finalized, successive releases can be made release candidates. It is traditional that release managers use their Apache home space to make available release candidates. Release signatures should be included.

Once the release has been cut, a vote should be done by the PPMC to validate the release. Once approved by the PPMC another vote must be done by the Incubator PMC for release final approval. This should be done on the incubator general mailing list and include a link to the release artifacts, a link to the PPMC release vote thread and a link to the tag from which the release has been cut. 3 binding +1s are required by members of the Incubator PMC.

Announcing The Release

  1. Perform a release in JIRA and create a new release version in JIRA
  2. Update the download page for the release on the Website
  3. Mail the dev & user lists, and announce@apache.org
  4. Post a news entry on the Website
  5. Have a beer!

Announcements should be signed by the release manager with the key used to sign the release. Note that this may mean creating a plain text signature on the machine used to sign the release and then transferring this.

Announcements should be posted from the release manager's apache.org address.