Release Management

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 :

branch

internal release number

release manager(s)

Contact Release Manager before committing

0.9.7-r547073

 

Srinivasa Segu

Yes

1.0.x

1.0.5-SNAPSHOT

Heath Thomann, Donald Woods

Yes

1.1.x

1.1.1-SNAPSHOT

Patrick Linskey, Abe White

Yes

1.2.x

1.2.3-SNAPSHOT

Heath Thomann, Donald Woods

Yes

1.3.x

1.3.0-SNAPSHOT

N/A*

No

2.0.x

2.0.2-SNAPSHOT

Donald Woods, Heath Thomann

Yes

2.1.x

2.1.1-SNAPSHOT

Heath Thomann

Yes

2.2.x

2.2.1-SNAPSHOT

Albert Lee

Yes

trunk

2.3.0-SNAPSHOT

N/A*

No

* There are no formal releases for these branches.

Continuous Builds

We are using the Apache Hudson server for continuous builds of several releases. Please checkout the Automated Builds page for more details.