Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Shorter release cycles

Thanks Ian!

I agree with service releases. I know a few project that do service releases when they need, not tied to the train. It’s certainly more flexible for the projects to do what they need to do. But before we go that way, I want to make sure that when a user selects Check for Updates, that it picks up these off train, i.e. off simrel repo, service releases. I’ve heard anecdotal evidence in the past that this didn’t work.

Will have to let the June/Nov cycle soak a bit. What I don’t want to see is where one of the releases is more important than the other. Part of my objective behind the 6 month cycle is to change the culture so people are thinking we release every 6 months and that becomes our habit. If we were late enough in November or maybe into the first week of December, that might be OK. Or maybe we leave Neon in June and move to May in 2017. But then I’m not totally sold on May/Nov over Apr/Oct yet either.

Doug.

From: Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
Reply-To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Date: Tuesday, May 5, 2015 at 12:40 PM
To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Subject: Re: [eclipse.org-planning-council] Shorter release cycles

Doug, thank-you for starting this conversation. 

Let's challenge a few assumptions first. What is the point of having Service Releases (SRs) for the entire train? Do we need them? I understand that individual projects may want to have service releases, but does the train as a whole, need them? Historically we followed the schedule of the Eclipse project itself, and this is a good pattern for the platform, but do we need this for the entire train?

What if we had two releases each year, starting with 15.11 this fall (Nov 2015) and 16.06 next year (June 2016). The Eclipse project itself could keep it's same milestones and contribute it's SR1 to 15.11, but train itself would use milestones similar to what you suggest. (I'm suggesting June 2016 because that way the Eclipse project could keep the exact same milestones it already has).

This actually is less work simultaneous release because there is now only one stream. 

Thoughts?
Ian

On Mon, May 4, 2015 at 3:03 PM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
+1. But I think we have a huge part of it automated already.

Doug.

From: Pascal Rapicault <pascal@xxxxxxxxxxxx>
Reply-To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Date: Monday, May 4, 2015 at 5:29 PM
To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Subject: Re: [eclipse.org-planning-council] Shorter release cycles

The first step toward that would be to make sure that the complete process is automated.

On 05/04/2015 03:00 PM, Doug Schaefer wrote:
Hey gang, as RC0 hits, feature freeze for most, and committers scramble to get those last minute features in before missing the window, or pushing features out another 12 months, or for some pushing them out knowing September is just around the corner (guilty), I’d like to start formalizing a proposal to shorten the release cycles and hopefully make this time of the year less painful and give us better quality results in a more responsive fashion for our community.

I’ve mentioned it a few times now, but I’d like to see us move to a 6 month release cycle. For the growing number of projects releasing minor releases on service release vehicles while convenient at the time, the only good it has served was releasing more often on the train. But it’s a workaround that’s confusing to users and adopters and is fraught with issues for the projects. SR-1 is too early (only three months after the June release), and SR-2 is too late before the next June release as evidenced by the number of CQs for Mars that came in after the deadline, which funny enough was the same week as SR-2, so we were asked to submit CQ’s for a release we hadn’t even started yet.

I think 6 months is more natural. Ubuntu is famous for releasing that often. We could still deliver an SR 3 months after each release for fixes and only fixes (no minor releases allowed there any more). Milestone releases remain important and we can try and keep a 6 week cadence with those. As is the ramp down starting at RC0 maybe six weeks before release.

Releasing June and December may be an issue, especially in December. We could do like Ubuntu and do April/October. Or one of the other four choices. We have to watch out for the EclipseCon’s and where they line up.

I’m sure there’s lots of things to consider to make sure we understand the affects of this change. But I think we have time. The first 6 month release would not be this fall but an early release for Neon. And obviously, not everyone has to put together a minor release every 6 months, though I would encourage that.

Love to hear your thoughts pro and con and see how far we could take this idea or not.
Thanks,
Doug.

BTW, here is a rough sample schedule, assuming May/November. Not a lot of thought went into this but gives an idea where the milestones and service releases fall. And it’s fun to see it in ink :)

Sep 4 – 16.05 M1/Mars SR1
Oct 16 – 16.05 M2
Nov 27 – 16.05 M3
Jan 15 – 16.05 M4
Feb 26 – 16.05 M5/Mars SR2
Apr 8 – 16.05 M6/RC0
May 25 - 16.05 Release (Neon)

July 15 – 16.11 M1
Aug 26 – 16.11 M2/16.05 SR
Oct 14 – 16.11 M3/RC 0
Nov 30 – 16.11 Release

Jan 14 – 17.05 M1
Feb 25 – 17.05 M2/16.11 SR
Apr 7 – 17.05 M3/RC0
May 24 – 17.05 Release


_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxxhttps://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.


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



--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Back to the top