OpenJPA Release Management

• DistributionStrategy
• JPA 2.0 Roadmap
  • JPA 2.0 Development Process
  • JSR-317 20081031 Public Draft Tasks
• New Release Instructions (BETA)
  • Recovering from a vetoed release
  • Update release text files
• Releasing OpenJPA
  • OpenJPA Release Policy

Where should I put my fix?

Fixes should be targeted and committed on trunk first. Any other open releases are fair game, but may require approval from a release manager.

Regarding Release Managers

Once a formal release of OpenJPA has been approved, a release manager is assigned. The release manager is often (but not always) the same developer who performed the release. This release manager role is intended to be a long term branch maintainer who looks after the stability of a formal release.

The release manager(s) is(are) responsible for targeting fixes into a given version of OpenJPA.

• Release managers may indicate this by targeting a JIRA issue for their branch or may issue a blanket statement that any fix will be accepted.
• In general only the release manager(s) should target a JIRA issue for a branch which they support.
  • An exception to this rule is if the RM has committed changes for their branch and forgot to update the JIRA issue.
• Fixes should not be committed without RM approval. These changes may be reverted by the release manager.

Some general guidelines for release managers

• Fixes which are committed to an earlier release should also be present "up-stream". Ie a fix for 1.0.x should also appear in 1.2.x.
• Issues may not apply to every release, so the previous guideline may not always apply.

Release Managers for active branches.

The current release managers for the active branches of OpenJPA are :

* There are no formal releases for these branches.