"David M Williams"
Eclipse Planning Council
private list <eclipse.org-planning-council@xxxxxxxxxxx> Date:
06.07.2016 19:23 Subject:
Planning the release dates for Oxygen.0
and Neon.X update releases Sent by:
Thank you Nick. This starting point
(and subsequent discussions from others on this list) has been very helpful.
I have made a second pass at all the dates, based on the discussion on
this list, and in a few cases based on some initial misunderstandings of
changes we had already agreed to (but feel free to say if I am the one
- The Oxygen "GA" date should have been one week later. (The
fourth Wednesday of June). - The initial Oxygen milestones no longer have a "two week window"
which changes to a one week window mid-year. (In previous PC meetings we
agreed that was no longer needed). - For the update releases there is no longer a "warm-up" RC that
is 2 weeks earlier than RC2 -- we start off with "real" RCs and
only one week between each. Again, we agreed in previous meetings this
was no longer necessary since the vast majority of participating projects
are well skilled at this by now.
The "feedback" from this list I incorporated:
- The GA for the Update releases is on Wednesday's instead of Friday's
(with the exception of Neon.3 which is a Thursday, due to Java 9's schedule).
- The above change to Wednesday's was accomplished by having longer "quiet
periods" for the Update Releases, which I think is a good idea anyway,
since that extra buffer might be needed given this is the first year we
have done 3 Update Releases. Please review this carefully: One very significant change, when I crunched
the numbers, is that M6 can be delivered right before EclipseCon, instead
of after. This is the way we usually do it, and is generally preferred,
if EclipseCon is late enough in the year. This means that Neon.3 will GA
*during* EclipseCon, but, remember, this is with an extended quiet period,
so it should essentially be done before the conference begins. One potential controversy to review carefully: One thing I added was
deliverable relatively early
in the Update Release cycle (a month before the first RC). We had briefly
discussed this in previous meetings, but I do not recall if we finished
discussing it. The purpose of this checkpoint is primarily for projects
who are new to the Update Release or for those that have significant changes
to introduce. Conceptually, they are similar to a "milestone"
during normal development -- except that it is recommended that established
projects not participate in checkpoint just for bug fixes or minor changes,
plus no EPP's created for checkpoints. I have added a paragraph describing
what a checkpoint is, and added a line for them to the Update Release schedule.
The "hard part" is that the first one will be just a few weeks
away! 7/25 to 7/27. I personally think this is important addition to our
process now that we more explicitly allow new projects and "new releases"
to join during an Update Release, but feel free to say if anyone thinks
it makes things too hard or is unfair since it is a "late addition"
to the process. My hope is that new projects just joining will find it
beneficial since it gives them a time to learn and go through the mechanics
that will be less stressful than when we get to the RC period. Not to mention,
good for "us" since improves communication about what will be
new in the Update Release.
Also, please proof read the dates I have put in all the tables. You all
know how bad I am about that!
= = = = = = = = =
I also ask that we approve this plan now, via this mailing list, or I could
call a special meeting for next week if people wanted to discuss on the
If you object to anything in the plan, please say so, and say why, and
we'll call a meeting to get the plan resolved.
If you agree with the plan please indicate with a +1 to this list. I will
assume silence implies agreement so I will say if there are at least 2
+1's and no objections by, say, next Tuesday (noon, Eastern time), July
12, then we will call this plan official and I will announce the checkpoint
requirement and dates on cross-project list then. And, please remember,
this is just a plan, not a contract, so we can tweak the plan later, if
we learn new things or conditions change.
= = = = = = = = =
Boldt <nboldt@xxxxxxxxxx> To: "eclipse.org-planning-council@xxxxxxxxxxx"
<eclipse.org-planning-council@xxxxxxxxxxx>, Date: 07/04/2016
05:10 PM Subject: [eclipse.org-planning-council]
Planning the release dates for Oxygen.0 and
Neon.X update releases Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx
* - This means we have Neon.1 released the week before we release Oxygen.0.M2, which provides some buffer/breathing space.
** - But for Neon.2 and Oxygen.0.M4, they're slated to land on the same date - Dec 16. We could push one a week later but that's dangerous with holidays affecting developer availability. Therefore, we might need to move one of those a week earlier. If so, which one -- Oxygen.0.M4 or Neon.2?
*** - The other possible conflict is around Oxygen.0.M6, which drops around the same week as Devoxx US (2017/03/21 to 03/23), JDK 9 GA (2017/03/23), and the week after Neon.3. Should we move that one too, or is having Neon.3 just before Devoxx and M6 right after it a reasonable approach? (We could switch them and even add another week for Neon.3, since it's the LAST update for Neon and needs to definitely work with JDK 9. Therefore: Oxygen.0.M6: 03/17 or 03/24; Neon.3: 03/30.)
Another thing we could do is move the GA dates for the update releases to Wednesdays instead of Fridays, so there can be a better marketing splash mid-week.