I've removed it. I just meant to cross-reference,
and not lose your proposal. I thought it similar due to the "May"
and "November" time frames ... but, agree, that was only similarity
with that particular proposal, which was struck down anyway on a couple
I think I did capture your other points,
... the October one starting with "Another strong candidate for "rhythm"
... As well as mention "The problem
of individual projects needing to roll-out important fixes "off schedule"
is not addressed ..."
But by all means, feel free to edit
the wiki, if more needs to be said on either point.
In my notes I try to avoid associating
names with proposals or comments, so the ideas can be evaluated on their
merits, rather than on the reputation of who said it, but any planning
council member is welcome to add their personal views if they feel that
is important and constructive.
Doug Schaefer <dschaefer@xxxxxxx> To:
Eclipse Planning Council
private list <eclipse.org-planning-council@xxxxxxxxxxx>, Date:
09/02/2015 03:48 PM Subject:
Reminder of first Wednesday meeting:9/2, 12 noon Sent by:
I’d remove the “Similar to Doug’s proposal”.
I never proposed 4 releases per year (and I still don’t think I like it).
I had originally proposed 6 month cycles but not sure that meets the requirement
of releasing as often as we need and is at this point a step backwards
from our current 3-5-4 cycle.
My actual proposal, which wasn’t captured,
at this point is to move the September release to October to make it evenly
spaced but 3 releases per year. Projects should be free to release service
releases at any time if we can share how to update individual projects
with Check for Updates.
Just clarifying my position. The front
runner seems to be four releases per year. But I’m not going to take credit
for it ;), other than to avoid releasing in the second half of December.