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.
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 build schedule.
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.
When there is a maintenance release under development, there are weekly maintenance stream builds on Wednesday at 8am EST with performance tests.
Any deviations from the regular weekly build schedule can be found on the releng build schedule.
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 week. Extra care needs to be taken as milestone week approaches to avoid disrupting the carefully timed test, fix, and build cycle of the milestone week itself.
The week of a milestone has its own special schedule. Generally this involves:
- 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
- Builds every 5 hours on Monday, with the aim of producing a "test candidate" build
- A full day of testing on Tuesday, with no builds at all so committers aren't tempted to divert away from testing efforts to fix and release code.
- Builds every 5 hours 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.
- On Friday the build is packaged up and rsynced to the eclipse.org servers. There is much rejoicing, and/or committers dive into the next milestone of development.
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.
The Eclipse and Equinox projects follow the annual eclipse.org simutaneous release schedule. Traditionally 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. Very large game-changing or potentially widely distabilizing changes are generally released between M1 and M4. All major new features generally appear by M5 at the latest (with further polish and improvement afterwards). 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. All feature work is completed by the end of M7, which is the final milestone.