Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Planning the release dates for Oxygen.0 and Neon.X update releases

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 misunderstanding :)

I would suggest to review the Oxygen dates first, since the Neon update releases are derived from them (for the most part).

The most significant changes I have made:

- 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 a checkpoint 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 phone.

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.

= = = = = = = = =



From:        Nick Boldt <nboldt@xxxxxxxxxx>
To:        "" <>,
Date:        07/04/2016 05:10 PM
Subject:        [] Planning the release dates for        Oxygen.0 and Neon.X update releases
Sent by:

I've updated the wiki with some *proposed* Neon.x and Oxygen.0 dates.

Some questions/concerns are listed below. Here's a summary of the
release (GA) dates.

Neon.X GA dates are:

Neon.1: 09/23*
Neon.2: 12/16**
Neon.3: 03/17***

Oxygen.0 milestone dates are:

M1: 08/16
M2: 09/30*
M3: 11/11
M4: 12/16**
M5: 02/03
M6: 03/24***
M7: 05/05
RC1: 05/19
RC2: 05/26
RC3: 06/02
RC4: 06/09
GA: 06/21

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

What do you think?

Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
_______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top