[CONF] OpenJPA > Release Management

[confluence]

Release Management Page edited by Michael Dick Changes (5) ... || branch || internal release number || release manager(s)|| Contact Release Manager before committing || | 0.9.7-r547073 | | Srinivasa Segu | Yes | | 1.0.x | 1.0.45-SNAPSHOT | Michael Dick, Donald Woods | Yes | | 1.1.x | 1.1.1-SNAPSHOT | Patrick Linskey, Abe White | Yes | | 1.2.x | 1.2.23-SNAPSHOT | Michael Dick, Donald Woods | Yes | | 1.3.x | 1.3.0-SNAPSHOT | N/A* | No | | 2.0.x | 2.0.12-SNAPSHOT | Donald Woods, Michael Dick | Yes | | trunk | 2.1.0-SNAPSHOT | Donald Woods, Michael Dick | No | | 2.1.x | 2.1.1-SNAPSHOT | Michael Dick | Yes | | trunk | 2.2.0-SNAPSHOT | N/A*| No | \* There are no formal releases for these branches. ... Full Content Release Management 2.1 Roadmap Apache Nexus Release Process (1.2.x-2.1.x) Release Setup JPA 2.0 Roadmap JPA 2.0 Development Process JPA 2.0 Iterations JPA 2.0 Presentations JPA 2.0 Tasks JPA 2.0 Test Coverage JSR-317 20081031 Public Draft Tasks OpenJPA 2.0.0 OpenJPA 2.0.0 Beta OpenJPA 2.0.0 Beta 2 OpenJPA 2.0.0 Beta 3 OpenJPA 2.0.0 Early Access 2 OpenJPA 2.0.0 Milestone 3 OpenJPA 2.0.1 Releasing OpenJPA 1.0.x or 1.1.x (Old SCP Steps) OpenJPA Release Policy Releasing OpenJPA 1.2.x (Old SCP Steps) Recovering from a vetoed release Running OpenJPA Examples Update release text files Verifying release signatures 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 Michael Dick, Donald Woods Yes 1.1.x 1.1.1-SNAPSHOT Patrick Linskey, Abe White Yes 1.2.x 1.2.3-SNAPSHOT Michael Dick, Donald Woods Yes 1.3.x 1.3.0-SNAPSHOT N/A* No 2.0.x 2.0.2-SNAPSHOT Donald Woods, Michael Dick Yes 2.1.x 2.1.1-SNAPSHOT Michael Dick Yes trunk 2.2.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. Change Notification Preferences View Online | View Changes | Add Comment