Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Simultaneous Release Brainstorming
Option 2 also has my +1.

About announcing to cross-project, I 'd suggest we have a better idea about the implications for participating projects before we just throw out the idea. We need to be pedagogical that the change does not mean that projects will be force to move to such a cadence etc. 

What about starting a FAQ on the wiki with the common questions we can already think about? Adding a link to this FAQ in your announcement to cross project will certainly help.

Also, here are some comments about your draft email:

The Planning Council proposes to change the simultaneous release cadence after Photon to give up with the year long ramp-up to the release for a rolling release.

Are we only making a proposal or are did we already decide about a couple of things? We need to be clear about what we decided and what is still open to comments / feedback as I guess we don't want to start infinite discussions about all of these.


After Photon :
* The releases will occur almost every xx weeks.

I would explain that we would like to move from a 1 year release cycle to a X weeks release cycle and explain the main motivations. I would also draft the GA dates: end of June, September, December, March.

* All the work will be done only on one stream.

While everyone at the planning council knows what it means, we would need to explain that there will be no more service releases for simrel, but it does not prevent individual projects to do so.

* And that only one repository will be used that will be continuously updated. A stable "latest" update site will be used to allow the user to update continuously.

I'm not sure to fully map that back to our discussions. Would you please elaborate? By "only one" you mean a global aggregated one of all simrel releases starting after photon? and latest pointing the latest component of this single aggregated one? Then "latest" is not "stable", it's a moving target pointing to the latest stable.

* Specific update sites will be available to reference any release. No composite repos will be built.

I don't get this line.

* The opt-in process will evolve, mostly projects would be assumed "in" and someone will take care of cleaning the outdated projects from time to time.

"someone" => we need to clear that out before going public. I guess that stating "the planning council" would enough for public announcement.

* It would be possible to add, update and remove API on any release.

Add that each project is responsible for its API deprecation policy.


The following release cycle planning is proposed:
C1 Friday Week 3 Checkpoint
M1 Friday Week x
C2 Friday Week x
RC1 Friday Week x API & Feature freeze
RC2 Friday Week x, it is assumed all code is done by the end of RC2.
GA Wednesday Week 12

explain what means "C" and what it is, how is it different from milestones and RC.


Due to this rolling release, our yearly code name pattern does not make sense anymore. Consequently, we propose a yearly.monthly pattern, for instance the releases after Photon would be :
Eclipse 2018.09, Eclipse 2018.12, Eclipse 2019.03, Eclipse 2019.06...

Do you really want to get feedback about it? People will probably focus on this part instead of the other (look at what happened with EE4J/Eclipse Jakarta EE). We should come with a decision, or a poll with different choices, but no open discussion.

Also, what about taking the opportunity to moving to a rolling release to make it clear that the simrel is specific entity, e.g., by naming it Eclipse Simultaneous Release 2018.09?

Cheers,


--
Mikaël Barbero - Eclipse Foundation
IT Services - Release Engineering
📱 (+33) 642 028 039
🐦 @mikbarbero

Le 26 févr. 2018 à 20:08, Aleksandar Kurtakov <akurtako@xxxxxxxxxx> a écrit :



On Mon, Feb 26, 2018 at 7:34 PM, Nick Boldt <nboldt@xxxxxxxxxx> wrote:
Had a look at the spreadsheet, which seems to show 3 sets of date options. To make it a bit easier to grok, here are those sets of GA dates -- I've omitted the other dates so we can just focus on the best solution for when to drop GA releases.

Option 1: GA dates near end of month, 13 week cycles
 2018.09 GA on 2018/09/26
 2018.12 GA on 2018/12/27
 2019.03 GA on 2019/03/27
 2019.06 GA on 2019/06/26
 2019.09 GA on 2019/09/25
 2019.12 GA on 2019/12/24
 2020.03 GA on 2020/03/25
 2020.06 GA on 2020/06/24
 2020.09 GA on 2020/09/23
 2020.12 GA on 2020/12/23

Option 2: GA dates near middle of month, 13 week cycles
 2018.09 GA on 2018/09/19
 2018.12 GA on 2018/12/19
 2019.03 GA on 2019/03/20
 2019.06 GA on 2019/06/19
 2019.09 GA on 2019/09/18
 2019.12 GA on 2019/12/18
 2020.03 GA on 2020/03/18
 2020.06 GA on 2020/06/17
 2020.09 GA on 2020/09/16
 2020.12 GA on 2020/12/16

Option 3: 12 week cycles w/ buffer weeks
 2018.09 GA on 2018/09/19
 2018.12 GA on 2018/12/12
 2019.03 GA on 2019/03/06
 2019.06 GA on 2019/06/05
 2019.09 GA on 2019/09/04
 2019.12 GA on 2019/12/04
 2020.03 GA on 2020/03/04
 2020.06 GA on 2020/06/03
 2020.09 GA on 2020/09/02
 2020.12 GA on 2020/12/02

I like option 2 the best here, as GA releases land in the middle of the month, or at least a week before the usual Dec/Jan and July holidays hit. However, mid-march is also a time when parents are wrangling kids due to March Break / school closures. 


I like option 2 too. Especially the december release time. And school vacations here are early April so not on issue for me :).
 

Option 3 is also a good option, but I'm worried that having a release the first week of September might be impacted by Labo(u)r Day & back to school season, and it shortens the runway for the March releases, which could be impacted by people taking vacations in December through into January. 

What if we split the difference between options 2 and 3 and target dates not from the (2nd to the 6th) or the (16th to the 20th) of the month, but instead the (9th to the 13th) ? So... something like this:

Option 4: 12 week cycles w/ buffer weeks (v2)
 2018.09 GA on 2018/09/12
 2018.12 GA on 2018/12/12
 2019.03 GA on 2019/03/13
 2019.06 GA on 2019/06/12
 2019.09 GA on 2019/09/11
 2019.12 GA on 2019/12/11
 2020.03 GA on 2020/03/11
 2020.06 GA on 2020/06/10
 2020.09 GA on 2020/09/09
 2020.12 GA on 2020/12/09

Thoughts?

Nick




On Mon, Feb 26, 2018 at 12:10 PM, Mélanie Bats <melanie.bats@xxxxxxx> wrote:
Hi all,

I finally find the time to prepare the possible schedule for the post photon releases according to :
* 13 weeks cadence as proposed by Nick (solution 1 & 2)
* 12 weeks cadence as discussed durinig our last call (solution 3)

You can find the two possibility on this document : https://docs.google.com/spreadsheets/d/1BZywK-gKbK-fmcEkxv550OHmw01xEN07RK9LMPSE40g/edit?usp=sharing

I will send this email to cross project this week to share our plan with the whole community :

"Hi,

The Planning Council proposes to change the simultaneous release cadence after Photon to give up with the year long ramp-up to the release for a rolling release.

After Photon :
* The releases will occur almost every xx weeks.
* All the work will be done only on one stream.
* And that only one repository will be used that will be continuously updated. A stable "latest" update site will be used to allow the user to update continuously.
* Specific update sites will be available to reference any release. No composite repos will be built.
* The opt-in process will evolve, mostly projects would be assumed "in" and someone will take care of cleaning the outdated projects from time to time.
* It would be possible to add, update and remove API on any release.

The following release cycle planning is proposed:
C1 Friday Week 3 Checkpoint
M1 Friday Week x
C2 Friday Week x
RC1 Friday Week x API & Feature freeze
RC2 Friday Week x, it is assumed all code is done by the end of RC2.
GA Wednesday Week 12

Due to this rolling release, our yearly code name pattern does not make sense anymore. Consequently, we propose a yearly.monthly pattern, for instance the releases after Photon would be :
Eclipse 2018.09, Eclipse 2018.12, Eclipse 2019.03, Eclipse 2019.06...

What do you think?
"

Thanks for your reviews and comments,

-- 
Mélanie Bats
CTO
+33 7 87 69 42 84
+33 5 34 57 16 29
@melaniebats

*Obeo*
25 Boulevard Victor Hugo - Colomiers - France
http://www.obeo.fr
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

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.



-- 
Nick Boldt
Senior Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com



“The Only Thing That Is Constant Is Change” - Heraclitus

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

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.



-- 
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

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.

Attachment: signature.asc
Description: Message signed with OpenPGP

Back to the top