Skip to main content
Jump to: navigation, search

Difference between revisions of "Neon/Simultaneous Release Plan"

(Initial draft to begin planning process)
 
m (Incorporate the "Update Release" terminology)
Line 1: Line 1:
  
'''NOTE: This document is in a "working state", unfinished, and not reviewed. An announcement will be made to cross-project list when it's ready for review or has been finalized. It will be considered formally official, by M4, if not sooner. Even before completely official, the initial milestones (M1 to M4) can be used for planning purposes.'''
+
'''NOTE: This document is partially complete, and partially in a working state. The initial 4 milestone dates (M1 to M4) have been agreed to, but not the remaining ones and not even the final release date, nor the dates of the update releases.'''
  
'''NOTE: For Neon, we are considering the possibility of having 3 "minor releases" after the main release, instead of 2 "service releases. Once we have all the dates planned out, we might want to have the release earlier, which would probably mean we would have one less milestone, than in previous years. All this is tentative, as of this writing ... just giving a "heads up" there might be such changes.'''
+
'''For Neon, we are considering having 3 update releases after the initial release, instead of 2 as in previous years. Once we have all the dates planned out, we might want to have the release slightly earlier, which would probably mean we would have one less milestone or one less release candidate, than in previous years. All this is tentative, as of this writing ... just giving a "heads up" there will be such differences from previous years.'''
 +
 
 +
'''An announcement will be made to cross-project list when this document is final. This will be by M4, if not sooner.'''
  
 
This document is for primarily for developers of the June 2016 Neon [[Simultaneous Release]].
 
This document is for primarily for developers of the June 2016 Neon [[Simultaneous Release]].
Line 88: Line 90:
 
This section, about assembling the repositories, is subject to change, as improvements in the process are made.
 
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, Juno '12, Kepler '13, Luna '14, and now Neon '15 builds. These are available in their own SCM repository. You can find more information about the history and organization by looking at some of the old, previous information on the [[Helios/Contributing_to_Helios_Build | Contributing to Helios Build]], [[Galileo/Build | Galileo Build]], [[Ganymede/Build | Ganymede Build]] and [[Europa/Build | Europa Build]] pages).
+
A number of utilities have been written to automate the assembly of Callisto '06, Europa '07, Ganymede '08, Galileo '09, Helios '10, Indigo '11, Juno '12, Kepler '13, Luna '14, Mars '15, and now Neon '16 builds. These are available in their own SCM repository. If interested in this history, you can find more information about the history and organization by looking at some of the old, previous information on the [[Helios/Contributing_to_Helios_Build | Contributing to Helios Build]], [[Galileo/Build | Galileo Build]], [[Ganymede/Build | Ganymede Build]] and [[Europa/Build | Europa Build]] pages).
  
 
With Neon we are using the [[Eclipse_b3/aggregator/manual|b3 Aggregator]].
 
With Neon we are using the [[Eclipse_b3/aggregator/manual|b3 Aggregator]].
Line 100: Line 102:
 
  http://download.eclipse.org/releases/neon
 
  http://download.eclipse.org/releases/neon
  
It contains the latest milestone, release candidate, eventually the release itself, and then eventually minor releases.
+
It contains the latest milestone, release candidate, eventually the release itself, and then eventually the update releases.
  
 
To obtain the latest working version, as we build up to a milestone or release, you can test the site at
 
To obtain the latest working version, as we build up to a milestone or release, you can test the site at
Line 106: Line 108:
 
  http://download.eclipse.org/releases/staging
 
  http://download.eclipse.org/releases/staging
  
===Minor Releases ===
+
=== Update Releases ===
  
Coordinated Minor 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 Minor 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.
+
[TBD: This section will change before final version of the plan, as there is a desire to have more than two update releases, for Neon.]
  
Instead of "staging", the roll-out of minor releases are kept at
+
Coordinated Update Releases are (always) scheduled for the fourth Friday of September, and the fourth Friday of February. Individual Projects may have their own maintenance releases, of course, at any time, if they need to, but all participants in the Yearly Release, are expected to participate in the Coordinated Update Releases. What new features that are added, or 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. To be explicit, new projects may join Update Releases, and participating projects may add new features or APIs (i.e. contribute Minor Releases) if they would like to. It is expected that many projects will primarily provide service-only updates, but it is up to each project. The only main "rule" is that no one can add breaking changes. This means no API breakages, and features can not be removed (for technical reasons) or refactored in a way that breaks others that "include" the feature;. If the contents of feature's change, due to refactoring, for example, it is best to do in a way that does not break existing adapters or projects that build against, or "include" that feature. Note: even breaking changes can be made, but those are the exception, rather than the rule, and must go through the Planning Council's formal Exception Process. Another "rule" is that new projects and even new features must essentially be complete, including release review records, by RC1. Anything later than that, must also go through the Planning Council's formal Exception Process.
  
http://download.eclipse.org/releases/maintenance
+
Instead of "staging", the roll-out of update releases are temporarily kept at
  
until the release, at which time the minor release joins the release (via composite repository) at the ".../releases/neon" site.
+
http://download.eclipse.org/releases/maintenance
  
[TODO: For Neon, we are considering having 3 "Minor Releases" instead of 2 "Service Releases" as we have in the past.]
+
until the release, at which time the update release joins the release (via composite repository) at the ".../releases/neon" site.
  
==== MR1 ====
+
==== Neon.1 ====
 
<!--
 
<!--
 
GA: 9/25/2016 (fourth Friday of September)
 
GA: 9/25/2016 (fourth Friday of September)
  
In the MR1 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.
+
In the Neon.1 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.
 
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.
Line 176: Line 178:
 
| 9/18
 
| 9/18
 
|-
 
|-
! align="right" | Neon MR1 ("GA")
+
! align="right" | Neon.1 ("GA")
 
| quiet: 9/18
 
| quiet: 9/18
 
| quiet: 9/21
 
| quiet: 9/21
Line 185: Line 187:
 
|}
 
|}
 
-->
 
-->
==== MR2 ====
+
==== Neon.2 ====
 
<!--
 
<!--
 
2/26/2017 (fourth Friday of February)
 
2/26/2017 (fourth Friday of February)
  
Rampdown principles similar to MR1.
+
Rampdown principles similar to Neon.1.
  
  
Line 234: Line 236:
 
| 2/19
 
| 2/19
 
|-
 
|-
! align="right" | Neon MR2 ("GA")
+
! align="right" | Neon.2 ("GA")
 
| quiet: 2/19
 
| quiet: 2/19
 
| quiet: 2/22
 
| quiet: 2/22
Line 243: Line 245:
 
|}
 
|}
 
-->
 
-->
==== MR3 ====
+
==== Neon.3 ====
 
<!--
 
<!--
 
2/26/2017 (fourth Friday of February)
 
2/26/2017 (fourth Friday of February)
  
Rampdown principles similar to MR1.
+
Rampdown principles similar to Neon.1.
  
  
Line 292: Line 294:
 
| 2/19
 
| 2/19
 
|-
 
|-
! align="right" | Neon MR2 ("GA")
+
! align="right" | Neon.3 ("GA")
 
| quiet: 2/19
 
| quiet: 2/19
 
| quiet: 2/22
 
| quiet: 2/22

Revision as of 14:38, 14 August 2015

NOTE: This document is partially complete, and partially in a working state. The initial 4 milestone dates (M1 to M4) have been agreed to, but not the remaining ones and not even the final release date, nor the dates of the update releases.

For Neon, we are considering having 3 update releases after the initial release, instead of 2 as in previous years. Once we have all the dates planned out, we might want to have the release slightly earlier, which would probably mean we would have one less milestone or one less release candidate, than in previous years. All this is tentative, as of this writing ... just giving a "heads up" there will be such differences from previous years.

An announcement will be made to cross-project list when this document is final. This will be by M4, if not sooner.

This document is for primarily for developers of the June 2016 Neon Simultaneous Release.


Requirements For Participation

Projects that are part of Neon 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 "+4" coming last (only EPP packages). 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 Neon Release. Projects are free to have their own schedules as long as they meet the Neon 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 Neon 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). Also, to emphasize, the dates represent the last possible date to contribute ... projects are encourage to provide "warm-up" builds a week or two earlier, when possible, as this often helps expose issues that other teams need discussion or that other teams need to react to, before their final delivery.

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 that have a "cross-project" impact.

Schedule

                                                              Elapsed Weeks
       End Date                      Span from +0         for +0    for EPP avail
M1  Friday, August 21, 2015           08/07 to 08/21          6         8   (from previous release GA)
M2  Friday, October 02                09/18 to 10/02          6         6   (from M1)
M3  Friday, November 13               10/30 to 11/13          6         6   (from M2)
M4  Friday, December 18               12/11 to 12/18          6         5   (from M3) (shift from 2 week window to 1 week window)
M5  Friday, February 05, 2016         01/29 to 02/05          7         7   (from M4) (extra week for end-of-year holidays)
  EclipseCon! (03?/?? to 03?/??)
M6  Friday, March 25                  03/18 to 03/25          7         7   (from M5) (extra week for EclipseCon)
M7  Friday, May 06                    04/29 to 05/06          6         6   (from M6)
RC1 Friday, May 20                    05/13 to 05/20          2         2   (from M7)
RC2 Friday, May 27                    05/20 to 05/27          1         1   (from RC1)
RC3 Friday, June 03                   05/27 to 06/03          1         1   (from RC2)
RC4 Friday, June 10                   06/03 to 06/10          1         1   (from RC3)
Quiet week, June 13 to June 17
 (no builds during "quiet week", assumed all code is done by end of RC4
Release Wednesday, June 22, 2016



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 Neon 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
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.

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 Neon 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, Juno '12, Kepler '13, Luna '14, Mars '15, and now Neon '16 builds. These are available in their own SCM repository. If interested in this history, 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 Neon we are using the b3 Aggregator.

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

p2 Repository

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

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

It contains the latest milestone, release candidate, eventually the release itself, and then eventually the update 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

Update Releases

[TBD: This section will change before final version of the plan, as there is a desire to have more than two update releases, for Neon.]

Coordinated Update Releases are (always) scheduled for the fourth Friday of September, and the fourth Friday of February. Individual Projects may have their own maintenance releases, of course, at any time, if they need to, but all participants in the Yearly Release, are expected to participate in the Coordinated Update Releases. What new features that are added, or 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. To be explicit, new projects may join Update Releases, and participating projects may add new features or APIs (i.e. contribute Minor Releases) if they would like to. It is expected that many projects will primarily provide service-only updates, but it is up to each project. The only main "rule" is that no one can add breaking changes. This means no API breakages, and features can not be removed (for technical reasons) or refactored in a way that breaks others that "include" the feature;. If the contents of feature's change, due to refactoring, for example, it is best to do in a way that does not break existing adapters or projects that build against, or "include" that feature. Note: even breaking changes can be made, but those are the exception, rather than the rule, and must go through the Planning Council's formal Exception Process. Another "rule" is that new projects and even new features must essentially be complete, including release review records, by RC1. Anything later than that, must also go through the Planning Council's formal Exception Process.

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

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

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

Neon.1

Neon.2

Neon.3

Copyright © Eclipse Foundation, Inc. All Rights Reserved.