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 "Eclipse/Rhythm"

(Weeks)
m (Milestones)
(19 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
The Eclipse and Equinox projects follow a well established build and development rhythm. Getting to know this rhythm will help you to become a better Eclipse/Equinox contributor or committer. If you have a feature request or favorite bug that you'd like to see fixed, it's also useful to know about this rhythm so you can understand when is a good time to push on a bug, and to understand why your bug seems to be ignored for a long time and then suddenly get fixed much later.
 
The Eclipse and Equinox projects follow a well established build and development rhythm. Getting to know this rhythm will help you to become a better Eclipse/Equinox contributor or committer. If you have a feature request or favorite bug that you'd like to see fixed, it's also useful to know about this rhythm so you can understand when is a good time to push on a bug, and to understand why your bug seems to be ignored for a long time and then suddenly get fixed much later.
  
Much like the earth, moon and sun have intertwined rhythms of rotation that create the days, tides, and seasons, the Eclipse project has a number of different layers to its development rhythm.
+
All of the information here is general guidance and advice rather than formal policy. Consult the build schedule or other knowledgeable committers in your area for the most accurate and up to date information. Some component teams operate differently than others, so if you are interested in working on a particular component it's a good idea to find out the local customs and practices of that component in case they differ from the general advice here.
  
 
== Days ==
 
== Days ==
  
Each day at 8PM EST/EDT is the "nightly" build. These builds run against CVS HEAD, so whatever is in the repository at the time the build checkout occurs is what gets built and tested. Releasing code between 8-10PM is generally a bad idea because you may be caught in the middle of the checkout and cause compile errors in the build. Performance tests typically run on the Thursday and Saturday nightly builds, so if you have performance fixes you want to verify, getting them in before those builds is helpful. Any deviations from the regular nightly build schedule can be found on the releng [http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html build schedule].
+
Each day at 8PM EST/EDT is the nightly build (sometimes called the N-build). These builds run against the HEAD revision in the master branch of the Git repository, so whatever is in the repository at the time the build checkout occurs is what gets built and tested. Releasing code between 8-10PM is generally a bad idea because you may be caught in the middle of the checkout and cause compile errors in the build. Performance tests typically run on the Thursday and Saturday nightly builds, so if you have performance fixes you want to verify, getting them in before those builds is helpful. Any deviations from the regular nightly build schedule can be found on the releng [http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html build schedule].
  
 
== Weeks ==
 
== Weeks ==
  
On a weekly basis, integration builds are every Tuesday morning. Rebuilds occur if needed on Wednesday. These builds run against tags, so you can precisely what you want to release to the build, and when. If you release changes on Monday night there is no chance to verify in a nightly build before contributing to a real build, so extra care is needed when releasing last minute changes. A good time to release larger changes is around Wednesday after the weekly build is out of the way.
+
On a weekly basis, integration builds are every Tuesday morning (I-build). Rebuilds occur if needed on Wednesday. These builds run against the designated build branch for each repository. Some repositories build out of master, some build out of a branch called "integration". To find out what branch is used for a particular repository, consult the [http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/tree/org.eclipse.releng/tagging/repositories.txt repositories.txt] file. Only release changes to the build branch if you intend for it to be included in the integration builds. If you release changes on Monday night there is no chance to verify in a nightly build before contributing to a real build, so extra care is needed when releasing last minute changes. Avoid pushing any further commits to the build branch in the first two hours of the build - you don't want to break a build by having it pick up part of a released set of changes. A good time to release larger changes is around Wednesday after the weekly build is out of the way.
  
When there is a maintenance release under development, there are weekly maintenance stream builds on Wednesday at 8am EST with performance tests.
+
When there is a maintenance release under development (generally July-February), there are weekly maintenance stream builds on Wednesday at 8am EST with performance tests (M-build).
  
== Months ==
+
Any deviations from the regular weekly build schedule can be found on the releng [http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html build schedule].
  
== Years ==
+
== Milestones ==
  
 +
Eclipse project milestones occur on roughly 6-week intervals. There is typically an extra week allocated for holidays around Christmas, and an extra week on the milestone that spans [http://eclipsecon.org EclipseCon]. Final milestone builds generally occur on a Friday (ideally Thursday, but sometimes on Saturday if things go really wrong). The very beginning of a milestone is a great time to be releasing your biggest code changes. This gives a month or more of builds to shake out any bugs before hitting the milestone stabilization week. Extra care needs to be taken as milestone stabilization week approaches to avoid disrupting the carefully timed test, fix, and build cycle of the milestone stabilization week itself. During that stabilization week, the code base is frozen from Tuesday onwards, except to fix regressions that are found during that week's testing. Anything else should be considered an exception and be reviewed and approved not only by the project lead but also by the PMC. 
 +
 +
The stabilization week of a milestone has its own special schedule. Generally, this involves:
 +
* No "Nightly" builds, but two I-builds per day, Monday through Wednesday.
 +
* A "warm-up" build on Sunday. This is a last chance to get in changes and verify them before the milestone week begins in earnest. Changes made on Monday must be tested very carefully before committing them.
 +
* Two builds on Monday, with the aim of producing a "test candidate" build to be used during Tuesday's testing.
 +
* A full day of testing on Tuesday. While builds continue on Tuesday, that is simply to have something scheduled, in case there is a bug so bad it interferes with testing, plus it is to help committers in our wide-spread timezones. Committers should not feel tempted to divert away from testing efforts to fix and release code simply because there are builds on Tuesday. Ideally, component leads will prepare a brief list of new features to test or bugs to verify. If in doubt, ask your component lead and/or test "Eclipse as a whole" -- try things you normally don't use, try a "mouseless test", read the help for various dialogs, etc.
 +
* Two builds I-builds on Wednesday, with the aim to produce a candidate milestone build to be ready on Thursday morning
 +
* No builds are scheduled on Thursday, but rebuilds can be requested by committers to release fixes for severe or high impact bugs. Thursday is the formal "sign-off" day. Before signing off, component leads need to decide if re-testing is required, or if they can simply confirm no changes have been made since the last good test.
 +
* On Friday the build is packaged, renamed, put in place on download servers at eclipse.org. There is much rejoicing, and/or committers dive into the next milestone of development. But, please remember the main branches remain frozen until the official note that the milestone is ready (That is, your component "signing-off" is not sufficient. There is always a chance a rebuild will be needed.)
 +
 +
Different components will have various other rituals during milestone week. Some teams like to verify each bug fixed during the milestone, and others may have different criteria for what fixes are appropriate on any given day of milestone week. Consult with a seasoned committer on the component you are interested in to learn the local customs during milestone week.
 +
 +
Any deviations from the regular milestone week build schedule can be found on the releng [http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html build schedule].
 +
 +
== Releases ==
 +
 +
The Eclipse and Equinox projects follow the annual eclipse.org simutaneous release schedule. Typically this means:
 +
* A major annual release at the end of June
 +
* A first service release at the end of September
 +
* A second service release at the end of February
 +
 +
The major release is broken into milestones. The kinds of changes that are released can vary greatly from milestone to milestone. Many committers take holidays during the first milestone (M1), as it immediately follows the busy release period. You may have trouble getting hold of a committer or getting your favourite bug release during that month or so following a major release.
 +
 +
Very large game-changing or potentially widely destabilizing changes are generally released between M1 and M4. All major new features generally appear by M5 at the latest (with further polish and improvement afterward). Don't bother asking for very large new features in the current release cycle once M5 is past. M6 is devoted to finalizing the API. If you want an API change in, you better make sure it happens by M6 or you'll need to wait until the start of the next release cycle.
 +
 +
The milestone immediately before EclipseCon is usually particularly busy, with most committers quite focused on getting their nifty new features in place in time to wow EclipseCon audiences. This is the best opportunity of the year to advertise new features so there is always a strong desire to get at least an initial release of new features by then. There is also heightened concern about bloopers appearing in this milestone that might make the current release look bad in demos and tutorials at the conference. This milestone is usually either M5 or M6, and has several times resulted in the infamous [http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg07433.html M5a] or [http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg07700.html M5eh].
 +
 +
All feature work is completed by the end of M7, which is the final milestone. The M7 milestone is also known as Release Candidate 0 (RC0), denoting the start of the release end-game schedule. The release end-game involves progressively increasing testing and lock down on changes according to the end-game plan. The release end-game has its own special build schedule and conventions on what changes are appropriate at any given time. End-game plans can change slightly from release to release, but see the [http://www.eclipse.org/eclipse/development/freeze_plan_3.5.php Galileo freeze plan] for a flavour of the conventions and processes during the release end-game.
 +
 +
== References ==
 +
 +
* [http://www.eclipsecon.org/2005/presentations/econ2005-eclipse-way.pdf The Eclipse Way] - presentation by John Wiegand and Erich Gamma on the Eclipse project development process
 +
* [http://www.eclipse.org/membership/weather/2009/Current.php The Eclipse weather forecast]
 +
* [http://www.eclipse.org/projects/timeline/ Eclipse Foundation master release timeline]
  
 
[[Category:How to Contribute]]
 
[[Category:How to Contribute]]
 +
[[Category:Eclipse Project]]
 +
[[Category:Equinox]]
 +
[[Category:Eclipse_Platform_Releng| ]]

Revision as of 04:52, 19 April 2016

The Eclipse and Equinox projects follow a well established build and development rhythm. Getting to know this rhythm will help you to become a better Eclipse/Equinox contributor or committer. If you have a feature request or favorite bug that you'd like to see fixed, it's also useful to know about this rhythm so you can understand when is a good time to push on a bug, and to understand why your bug seems to be ignored for a long time and then suddenly get fixed much later.

All of the information here is general guidance and advice rather than formal policy. Consult the build schedule or other knowledgeable committers in your area for the most accurate and up to date information. Some component teams operate differently than others, so if you are interested in working on a particular component it's a good idea to find out the local customs and practices of that component in case they differ from the general advice here.

Days

Each day at 8PM EST/EDT is the nightly build (sometimes called the N-build). These builds run against the HEAD revision in the master branch of the Git repository, so whatever is in the repository at the time the build checkout occurs is what gets built and tested. Releasing code between 8-10PM is generally a bad idea because you may be caught in the middle of the checkout and cause compile errors in the build. Performance tests typically run on the Thursday and Saturday nightly builds, so if you have performance fixes you want to verify, getting them in before those builds is helpful. Any deviations from the regular nightly build schedule can be found on the releng build schedule.

Weeks

On a weekly basis, integration builds are every Tuesday morning (I-build). Rebuilds occur if needed on Wednesday. These builds run against the designated build branch for each repository. Some repositories build out of master, some build out of a branch called "integration". To find out what branch is used for a particular repository, consult the repositories.txt file. Only release changes to the build branch if you intend for it to be included in the integration builds. If you release changes on Monday night there is no chance to verify in a nightly build before contributing to a real build, so extra care is needed when releasing last minute changes. Avoid pushing any further commits to the build branch in the first two hours of the build - you don't want to break a build by having it pick up part of a released set of changes. A good time to release larger changes is around Wednesday after the weekly build is out of the way.

When there is a maintenance release under development (generally July-February), there are weekly maintenance stream builds on Wednesday at 8am EST with performance tests (M-build).

Any deviations from the regular weekly build schedule can be found on the releng build schedule.

Milestones

Eclipse project milestones occur on roughly 6-week intervals. There is typically an extra week allocated for holidays around Christmas, and an extra week on the milestone that spans EclipseCon. Final milestone builds generally occur on a Friday (ideally Thursday, but sometimes on Saturday if things go really wrong). The very beginning of a milestone is a great time to be releasing your biggest code changes. This gives a month or more of builds to shake out any bugs before hitting the milestone stabilization week. Extra care needs to be taken as milestone stabilization week approaches to avoid disrupting the carefully timed test, fix, and build cycle of the milestone stabilization week itself. During that stabilization week, the code base is frozen from Tuesday onwards, except to fix regressions that are found during that week's testing. Anything else should be considered an exception and be reviewed and approved not only by the project lead but also by the PMC.

The stabilization week of a milestone has its own special schedule. Generally, this involves:

  • No "Nightly" builds, but two I-builds per day, Monday through Wednesday.
  • A "warm-up" build on Sunday. This is a last chance to get in changes and verify them before the milestone week begins in earnest. Changes made on Monday must be tested very carefully before committing them.
  • Two builds on Monday, with the aim of producing a "test candidate" build to be used during Tuesday's testing.
  • A full day of testing on Tuesday. While builds continue on Tuesday, that is simply to have something scheduled, in case there is a bug so bad it interferes with testing, plus it is to help committers in our wide-spread timezones. Committers should not feel tempted to divert away from testing efforts to fix and release code simply because there are builds on Tuesday. Ideally, component leads will prepare a brief list of new features to test or bugs to verify. If in doubt, ask your component lead and/or test "Eclipse as a whole" -- try things you normally don't use, try a "mouseless test", read the help for various dialogs, etc.
  • Two builds I-builds on Wednesday, with the aim to produce a candidate milestone build to be ready on Thursday morning
  • No builds are scheduled on Thursday, but rebuilds can be requested by committers to release fixes for severe or high impact bugs. Thursday is the formal "sign-off" day. Before signing off, component leads need to decide if re-testing is required, or if they can simply confirm no changes have been made since the last good test.
  • On Friday the build is packaged, renamed, put in place on download servers at eclipse.org. There is much rejoicing, and/or committers dive into the next milestone of development. But, please remember the main branches remain frozen until the official note that the milestone is ready (That is, your component "signing-off" is not sufficient. There is always a chance a rebuild will be needed.)

Different components will have various other rituals during milestone week. Some teams like to verify each bug fixed during the milestone, and others may have different criteria for what fixes are appropriate on any given day of milestone week. Consult with a seasoned committer on the component you are interested in to learn the local customs during milestone week.

Any deviations from the regular milestone week build schedule can be found on the releng build schedule.

Releases

The Eclipse and Equinox projects follow the annual eclipse.org simutaneous release schedule. Typically this means:

  • A major annual release at the end of June
  • A first service release at the end of September
  • A second service release at the end of February

The major release is broken into milestones. The kinds of changes that are released can vary greatly from milestone to milestone. Many committers take holidays during the first milestone (M1), as it immediately follows the busy release period. You may have trouble getting hold of a committer or getting your favourite bug release during that month or so following a major release.

Very large game-changing or potentially widely destabilizing changes are generally released between M1 and M4. All major new features generally appear by M5 at the latest (with further polish and improvement afterward). Don't bother asking for very large new features in the current release cycle once M5 is past. M6 is devoted to finalizing the API. If you want an API change in, you better make sure it happens by M6 or you'll need to wait until the start of the next release cycle.

The milestone immediately before EclipseCon is usually particularly busy, with most committers quite focused on getting their nifty new features in place in time to wow EclipseCon audiences. This is the best opportunity of the year to advertise new features so there is always a strong desire to get at least an initial release of new features by then. There is also heightened concern about bloopers appearing in this milestone that might make the current release look bad in demos and tutorials at the conference. This milestone is usually either M5 or M6, and has several times resulted in the infamous M5a or M5eh.

All feature work is completed by the end of M7, which is the final milestone. The M7 milestone is also known as Release Candidate 0 (RC0), denoting the start of the release end-game schedule. The release end-game involves progressively increasing testing and lock down on changes according to the end-game plan. The release end-game has its own special build schedule and conventions on what changes are appropriate at any given time. End-game plans can change slightly from release to release, but see the Galileo freeze plan for a flavour of the conventions and processes during the release end-game.

References

Back to the top