Doug Schaefer <dschaefer@xxxxxxx>
Eclipse Planning Council
private list <eclipse.org-planning-council@xxxxxxxxxxx>
Next meeting, and some items to decide before next meeting
That’s why I proposed Mars.1, not Mars
1. The dot implies an increment on the Mars release.
+1 for not increasing version numbers.
I assume we are not taking about 'plugins / features' but rather the .product
files. However, I don't think we should increase them just because.
If EPP provides API itself, that should be versioned properly.
As for names, I'm fine with Mars 1 and
Mars 2, but are we sure we like the 0 offset thing? Is Mars 1 the first
release (the one that happened in June) or does Mars 1 come second, in
September? Will this confuse anyone?
On Mon, Jul 20, 2015 at 9:46 AM, Daniel
+1. We shouldn't abuse the terms and
only increase when appropriate.
You're scaring me. One only bumps the major version of a bundle/feature
if one actually breaks API, and many if not most downstream bundles specify
an upper bound that excludes major version increments for exactly that
reason. As such major version increments imply incompatibility and
downstream pain, which is of course not a good message at all. In
other words, version numbers are not a marketing message:
I think the "minor" wording doesn't actually improve anything,
especially given that some projects will do minor releases and some will
do service releases. Note how Max is assuming that the June release
is therefore a major release...
Maybe it's best to continue to focus on terminology that reflects what
the base platform is doing. Will they be doing service releases or
On 18/07/2015 2:32 AM, Max Rydahl Andersen wrote:
On point #1.
If we go and call it a minor release - should we also actually bump the
minor version of the epp packages ?
And by implication bump major every year ?
Note - none of this should imply anyone inside the release train must break
Api just that it is a possibility but we encourage keep things backwards
I personally think that would be a good message to send.
But interested in hearing arguments for/against it ?
But, there are two items for you to consider before then, and ideally come
to agreement. I am thinking they are not controversial, and we can
document agreement via this list by next week (7/24). But, if they are
controversial, we can discuss at August meeting.
1. One "todo" we have is to change the mis-perception that "new
things can go into Simultaneous Release repository only once per year".
I think one thing we can do, even for Mars, is to officially change the
name of September and February release. Currently called "Service
Release", it has been many years since that has been true, and the
only reason we haven't changed the name is because we could not think of
a better one. It was suggested at previous meeting (thanks Max) that "Minor
Release" would be appropriate.
So, I'd like to formally propose to change the name to "Minor Release"
(even for Mars) and change "SR" abbreviations to "MR"
the few places it is used. I do not think the "rules" change
over what is currently documented in our Policy
FAQ. I suppose that "policy"
should be moved into the Plan itself, since the Policy FAQ is not easy
Please indicate thumbs up or thumbs down, here to Planning Council list.
If there is disagreement, please be concrete as to why, and perhaps propose
alternatives. We can have more discussion at August meeting, if needed,
but I think to make a change like that, as early as possible would be better.
2. Another "todo" is the agree to a Neon
Simultaneous Release Plan.
While there is still a lot of work to do on the plan, as a whole, the thing
I'd like to get immediate agreement for is that the first 4 milestones
would be similar in duration and dates than in previous years. (M4 is in
mid-December, 2015). See Neon
Simultaneous Release Plan
for details. That would give individual projects (and us) something concrete
to plan for in near future, while we work out details of having more "Minor
Releases" for Neon.
Again, please indicate thumbs up or thumbs down, here to this list, and
feel free to say if anyone thinks that is an invalid "initial plan".