Changes between Version 2 and Version 3 of ReleasePractices/PostBetaMerges

Timestamp:

Oct 27, 2008, 1:17:02 PM (14 years ago)

Author:

Beman Dawes

Comment:

Add comment from Robert Ramey

ReleasePractices/PostBetaMerges

@@ -11 +11 @@
  *  '''Showstoppers.''' Criteria: Bugs or other problems so serious that the release is seriously compromised if not fixed. Procedure: After discussion on the developers list, release managers will specify how the problem is to be attacked, and what effect it will have on schedule.
 
- * '''Code changes and fixes.''' Procedure: Ask release managers for permission. Rationale: While we do want to fix problems, particularly regressions, stability is a major concern at this point in the release cycle.
+ * '''Code changes and fixes.''' Procedure: Ask release managers for permission. Libraries with regressions showing in trunk testing should not be merged into the release branch.  If it is discovered that this has occurred, then the merge should be reverted. Rationale: While we do want to fix problems, particularly regressions, stability is a major concern at this point in the release cycle.
 
  * '''Documentation fixes and other minor changes not affecting code.''' Criteria: Changes not requiring regression testing and unlikely to impact other libraries. Procedure: Merges to branches/release are OK, after fix applied to trunk, and do not require a release manager's permission. '''Important:''' If applicable, check the daily snapshot to verify the change did not break the documentation build.
@@ -21 +21 @@
 == Acknowledgments ==
 
-Joaquín M López Muñoz, John Maddock helped with the development of this policy.
+Joaquín M López Muñoz, John Maddock, and Robert Ramey made helpful suggestions during the development of this policy.
 
 ----