Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Orion/Plan"

(Past releases: fix bad release links)
(Merge edit by Snorthov.ca.ibm.com)
Line 14: Line 14:
 
During the last thirty days, development follows a different schedule.  
 
During the last thirty days, development follows a different schedule.  
 
To make sure we do not introduce any regressions right before the release, we do the following:
 
To make sure we do not introduce any regressions right before the release, we do the following:
# Keep working as usual for the first week of the wind-down. Typically no new features will be added at this time unless approved by the project lead
+
# Keep working as usual for the first week of the wind-down. Typically no new features will be added at this time unless approved by the project lead.
 
# Once the release review is complete (typically by the second week of the wind-down), development changes to the "last chance" stage to put in changes (with no new features), with each change requiring a +1 from one other committer. This continues for the next two weeks.
 
# Once the release review is complete (typically by the second week of the wind-down), development changes to the "last chance" stage to put in changes (with no new features), with each change requiring a +1 from one other committer. This continues for the next two weeks.
 
# The last week is reserved strictly for testing and making critical fixes, with any fix requiring a +1 from two committers (ideally one of the committers being the project lead).
 
# The last week is reserved strictly for testing and making critical fixes, with any fix requiring a +1 from two committers (ideally one of the committers being the project lead).

Revision as of 16:26, 5 December 2016

Current and future releases

Release Wind-down

As the development cycle gets closer to the release date, there is a general process we follow to ensure a successful and stable release.

When development reaches the final thirty days before release, two important steps begin the wind-down:

  1. The IP log is submitted. Before the logs are submitted, all outstanding dependencies must be checked and a decision made if they will appear in the upcoming release.
  2. A release review must be scheduled. This is done from the project page under a specific release.


During the last thirty days, development follows a different schedule. To make sure we do not introduce any regressions right before the release, we do the following:

  1. Keep working as usual for the first week of the wind-down. Typically no new features will be added at this time unless approved by the project lead.
  2. Once the release review is complete (typically by the second week of the wind-down), development changes to the "last chance" stage to put in changes (with no new features), with each change requiring a +1 from one other committer. This continues for the next two weeks.
  3. The last week is reserved strictly for testing and making critical fixes, with any fix requiring a +1 from two committers (ideally one of the committers being the project lead).
  4. After the release has been announced on the mailing list and planetorion, new and noteworthy blog posts are created for each area (tools, client, etc).

Past releases

Back to the top