So you wouldn't bump minor version when you add new features ?
Max,
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:
https://wiki.eclipse.org/Version_Numbering
David,
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 minor releases?
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 compatible.
I personally think that would be a
good message to send.
But interested in hearing arguments
for/against it ?
/max
We are not meeting again
until August 5,
See https://wiki.eclipse.org/Planning_Council/August_05_2015
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
to find.
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".
Thanks,
_______________________________________________
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.
|