• Page
• Discussion
• View source
• History

From Eclipsepedia

You do not have permission to do that, for the following reason:

You can view and copy the source of this page:

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 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]. == Weeks == On a weekly basis, integration builds are every Tuesday morning (I-build). 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. Avoid tagging any further changes in the first two hours of the build - the CVS checkout can sometimes take awhile, and 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 [http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html 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 [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 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 [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:Eclipse Project]] [[Category:Equinox]]

Return to Eclipse/Rhythm.