Difference between revisions of "Buckminster/Galileo Ramp-Down Policy"

From Eclipsepedia

Jump to: navigation, search
(New page: = Buckminster Ramp-down Policy for Galileo = Release Candidates: * RC1 - Build Mon, May 18 - Release Tue, May 19 * RC2 - Build Mon, May 25 - Release Tue, May 26 * RC3 - Build Mon, June 1...)
 
(Buckminster Ramp-down Policy for Galileo)
 
Line 12: Line 12:
 
API freeze on M7 (Mon, April 4)
 
API freeze on M7 (Mon, April 4)
  
Starting Fri, May 25 (after RC3 build), all commits must be accompanied with a notification to the buckminster-dev list providing a link to the bug that was fixed.
+
Starting Mon, June 1 (after RC3 build), all commits must be accompanied with a notification to the buckminster-dev list providing a link to the bug that was fixed.
  
 
The idea is to ensure we're only fixing bugs during the RC cycle. And as we get closer, it's important that we all understand what's changing and can object if too much is changing too late to ensure we stabilize by the end of the release.
 
The idea is to ensure we're only fixing bugs during the RC cycle. And as we get closer, it's important that we all understand what's changing and can object if too much is changing too late to ensure we stabilize by the end of the release.
  
 
Project lead will also continue to send countdown e-mails as we go to track open bugs.
 
Project lead will also continue to send countdown e-mails as we go to track open bugs.

Latest revision as of 02:58, 4 June 2009

[edit] Buckminster Ramp-down Policy for Galileo

Release Candidates:

  • RC1 - Build Mon, May 18 - Release Tue, May 19
  • RC2 - Build Mon, May 25 - Release Tue, May 26
  • RC3 - Build Mon, June 1 - Release Tue, June 2
  • RC4 - Build Mon, June 8 - Release Tue, June 9
  • Final - Build Mon, June 15 - Release Tue June 16

No new features will be added after M6 (Tue, March 17). API freeze on M7 (Mon, April 4)

Starting Mon, June 1 (after RC3 build), all commits must be accompanied with a notification to the buckminster-dev list providing a link to the bug that was fixed.

The idea is to ensure we're only fixing bugs during the RC cycle. And as we get closer, it's important that we all understand what's changing and can object if too much is changing too late to ensure we stabilize by the end of the release.

Project lead will also continue to send countdown e-mails as we go to track open bugs.