Re: [eclipse.org-planning-council] Shorter release cycles

[David M Williams <david_williams@xxxxxxxxxx>]

Doug, do you call it a "release"
because you want it to be able to include "major field" changes
(i.e. API breaking)? 
If not that, would an extra SR solve
the same issue? (An SR where we allow new features, as we do now.) 




From:      
 Doug Schaefer <dschaefer@xxxxxxx>
To:      
 Eclipse Planning Council
<eclipse.org-planning-council@xxxxxxxxxxx>, 
Date:      
 05/04/2015 03:01 PM
Subject:    
   [eclipse.org-planning-council]
Shorter release cycles
Sent by:    
   eclipse.org-planning-council-bounces@xxxxxxxxxxx

---

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