Juno/Simultaneous Release Plan

This document is for developers of the June 2012 Juno Simultaneous Release. Users and consumers should instead see the general Eclipse page for Juno.

Requirements For Participation

Projects that are part of Juno agree to abide by the requirements of the Eclipse yearly Simultaneous Release.

Milestones and Release Candidates

The Release is always on the fourth Wednesday of June. The milestone dates are at roughly 6 week intervals. Any end-of-cycle release-candidate (RC) dates are typically one week apart. Each project has their deliveries due at times offset from the end-date, so that the project dependencies can come together in a reasonable order. These delivery times are based on the dependencies between projects. They are labeled +0, +1, +2, and +3, with +0 coming first (the Platform) and +3 coming last (EPP). Projects themselves decide if they are +0, +1, +2, or +3. The actual time-offset represented by these intervals change over the course of the year of development, being several days at first, but then only one day near the end of the release. The following calendar is the official schedule of the overall Juno Release. Projects are free to have their own schedules as long as they meet the Juno deliverables.

Note that projects choose their own +n category based on major or primary dependencies. There are many cases where a project might have to deliver pieces of their code a little earlier, if some project depends on it, or a little later if they have a stray dependency. These sorts of deviations are left to the projects to work out, pair-wise, among themselves. Feel free to bring up complicated cases for discussion.

Given all these constraints, the exact dates for any particular year are pretty predictable. The following table summarizes the most significant Juno dates, but see the subsequent calendar for the important details. That is, your stuff is due earlier than these table dates! Projects need to deliver a week or two before these "end dates", depending on their chosen, committed offset category (+0, +1, etc).

After RC4 is quiet week. There will be no further builds. That time is reserved for final, in depth testing, and preparation for release. Emergency rebuilds might be considered, by following the usual Planning Council Exception Process, but only for serious, blocking regressions.

Schedule

                                                               Elapsed Weeks  
        End Date                      Span from +0         for RC0   for EPP avail
M1  Friday, August 19, 2011           08/05 to 08/19          6         8   (from previous release GA)
M2  Friday, September 30              09/16 to 09/30          6         6   (from M1)
M3  Friday, November 11               10/28 to 11/11          6         6   (from M2)
M4  Friday, December 16               12/09 to 12/16          6         5   (from M3) (shift from 2 week window to 1 week window)
M5  Friday, February 03, 2012         01/27 to 02/03          7         7   (from M4) (extra week for end of year holidays)
M6  Friday, March 23                  03/16 to 03/23          7         7   (from M5) (extra week from 53 week year)
 EclipseCon! (03/26 to 03/29) 
M7  Friday, May 11                    05/04 to 05/11          7         7   (from M6) (extra week for EclipseCon)
RC1 Friday, May 25                    05/18 to 05/25          2         2   (from M7)
RC2 Friday, June 01                   05/25 to 06/01          1         1   (from RC1)
RC3 Friday, June 08                   06/01 to 06/08          1         1   (from RC2)
RC4 Friday, June 15                   06/08 to 06/15          1         1   (from RC3)
Quiet time, June 16 to June 27
 (no builds during "quiet time", assumed all code is done by end of RC4                         
Release Wednesday, June 27, 2012

The calendar is available in the following formats: ICal,ATOM News Feed,HTML

Communication Channels

Cross-Project Milestone & RC Status Reporting

Only negative status needs to be reported. It is essential for many aspect of the simultaneous release that communication be prompt and clear, on many topics. One of the most important ones, is if someone is not meeting some date or delivery. Put another way, we assume everyone is on target and has delivered their stuff unless a note is sent to cross-project list that you are delayed. Its better to be up front about it, so everyone knows what to expect, rather than to hope things turn out ok at the very last minute, since if you "miss" without saying anything you are more likely to impact other people, and miss your chance to be part of the release.

Mailing Lists and Newsgroups

Eclipse projects have three communication channels: a mailing list for developers, a newsgroup for users, and Bugzilla. While Juno is not a "project" per se, it will use the same structure:

Developer mailing list

• cross-projects-issues-dev - mailing list for developers and releng (see archives). This is the list to use to discuss build issues, announce changes in plans, slippage in deliverables, etc.

Users news group

• eclipse.simultaneous-release - newsgroup for users (see archives)

Bugzilla

If there is any doubt about where a bug belongs, it can always start in the "Cross-Project" component. (Under Eclipse Foundation > Community). If it turns out to be a single-project's responsibility, it can be moved to that project. If it is a true cross-project bug, where several projects need to act, then it can stay in the cross-project component.

• Search in Eclipse Foundation > Community > Cross-Project
• Open a new Cross-Project bug

The Planning Council Mailing List

Because there has been confusion in the past, we'll be explicit here that the planning council mailing list (eclipse.org-planning-council) is for Planning Council business, not the Juno Release activities per se. While they sometimes overlap, there is no need to cross post. While anyone can request a subscription to the planning council list (for openness and transparency) the expectation is that only Planning Council members post to it.

Conference Calls

The Planning Council has regularly scheduled calls for Planning Council business. See conference calls.

But there are no planned calls for the release, per se, or for larger audiences, but they can be arranged if required or desired (for example, if needed for build coordination).

Builds and P2 repository

Builds (Aggregation)

This section, about assembling the repositories, is subject to change, as improvements in the process are made.

A number of utilities have been written to automate the assembly of Callisto '06, Europa '07, Ganymede '08, Galileo '09, Helios '10, Indigo '11 and now Juno '12 builds. These are available in their own CVS repository. You can find more information about the history and organization by looking at some of the old, previous information on the Contributing to Helios Build, Galileo Build, Ganymede Build and Europa Build pages).

With Juno we are using the b3 Aggregator.

The Contributing to Juno Build page is where you go to learn how to add your project to the Juno build (aggregation).

p2 Repository

To obtain the latest published bits from Juno, use this URL:

http://download.eclipse.org/releases/juno

It contains the latest milestone, release candidate, eventually the release itself, and then eventually service releases.

To obtain the latest working version, as we build up to a milestone or release, you can test the site at

http://download.eclipse.org/releases/staging

Service Releases

Coordinated Service Releases are (always) scheduled for the fourth Friday of September, and the fourth Friday of February. Individual Projects may have their own, of course, at any time, if they need to, but all participants in the Yearly Release, are expected to participate in the Coordinated Service Releases. What bugs are fixed, if any, is up to each Project to decide, but each Project must continue to "fit in", build, install, avoid conflicts, etc.

Instead of "staging", the roll-out of service releases are kept at

http://download.eclipse.org/releases/maintenance

until the release, at which time the service release joins the release (via composite repository) at the ".../releases/juno" site.

SR1

GA: 9/28/2012 (fourth Friday of September)

In the SR1 rampdown, as shown in the following table, there will be 4 RCs, each one of those spanning just one week, with projects staging themselves into the build just one day apart.

Projects may elect not to participate in any particular RC (and just contribute what's already there), but projects do have an obligation to fix any build problems that are related to their code or p2 repositories during each RC, if any such problems arise.

RC1 is really a "warm-up" RC, just to make sure we can still build, etc. Subsequent RCs are expected to be true "Release Candidates", suitable for acceptance testing, etc.

The Final week before GA will not have any further builds or contributions, but instead be reserved for final adopter testing and site preparations. Only emergency fixes for very serious regressions that effect many projects or the general ability to install or update will be considered as a reason to rebuild during the final quiet week.

The 'promote period' (9/24 to 9/28) will be the time projects put final zips and repository artifacts in their final release location (but, without displaying them or making them visible to p2) so they can propagate through the mirroring system (but not generally be "visible" to end users or p2, so that there really is a "simultaneous maintenance release"). At 9 AM (Eastern) on the GA date (9/28) projects can make their final maintenance releases visible. (Be sure to check cross-project list, first, to make sure there's not any last-minute blocking problems or changes to exact times).

Note: the time something is due is 5 PM (Eastern) and availability times are 9 AM (Eastern) unless otherwise communicated on cross-project list.

	+0 Fri.	+1 Mon.	+2 Tues.	+3 Wed.	EPP Thur.	Available Fri.
RC1 (Warmup)	8/17	8/20	8/21	8/22	8/23	8/24
RC2	8/31	9/3	9/4	9/5	9/6	9/7
RC3	9/7	9/10	9/11	9/12	9/13	9/14
RC4	9/14	9/17	9/18	9/19	9/20	9/21
Juno SR1 ("GA")	quiet: 9/21	quiet: 9/24	quiet: 9/25	quiet: 9/26	quiet: 9/27	GA: 9/28

SR2

2/22/2013 (fourth Friday of February)

Rampdown principles similar to SR1.

	+0 Fri.	+1 Mon.	+2 Tues.	+3 Wed.	EPP Thur.	Available Fri.
RC1 (Warmup)	1/11	1/14	1/15	1/16	1/17	1/18
RC2	1/25	1/28	1/29	1/30	1/31	2/1
RC3	2/1	2/4	2/5	2/6	2/7	2/8
RC4	2/8	2/10	2/12	2/13	2/14	2/15
Juno SR2 ("GA")	quiet: 2/15	quiet: 2/18	quiet: 2/19	quiet: 2/20	quiet: 2/21	GA: 2/22