David,
+1 for simply using numbers.
On 18/07/2015 6:37 PM, David M Williams
wrote:
Well, I sure am glad
I brought this topic
up early. Thanks for the comments, Ed, Max, and Doug.
So far, I like Doug's idea best,
of
just calling the "subsequent releases", Mars 1, Mars 2, etc.
That does leave open the possibility they might just be service
releases,
they might be minor, and, IMHO, eventually might even contain
"major"
updates (such as for "leaf" components, and where it is fairly
clear adopters would not be broken (if that's possible?).
So, that's not my formal
proposal: Mars
1, Mars 2 for this year.
I do like it sense it scales, and
because
it doesn't really "imply that much" ... but also does not "imply
too little" as current "Service Release" does.
To address some of the other
questions/issues.
Yes, EPP packages do have a version number. As of now, for past
2, maybe
3 releases, -- purely by popular demand -- it is set equal to
the platform's
release number. While not technically correct, it does act more
like a
"marketing number". I think probably fine to continue that,
until
it becomes a problem. I do not think people should use or
require those
epp features in other products, they should use the features
that make
up the EPP package.
And, as for the Platform itself.
Yes,
sometimes will be "just service", but, sometimes may be "minor"
releases too. (As one example, when Java 8 or Java 9 support is
added in
a "subsequent release".)
I do not think we should
arbitrarily
increase "major version" very year. At least, the major versions
of features and bundles. There's always been talk of having a
"marketing
number" somehow, somewhere, but, not sure right off what that
implies.
So, PC members, please weigh in
on proposal
to use "Mars 1", "Mars 2" ...
AND,
please indicate if you are happy,
or
not, leaving the first four milestones scheduled as in years
past. Details
in Neon
Simultaneous
Release Plan.
Thanks,
From:
Doug Schaefer
<dschaefer@xxxxxxx>
To:
Eclipse Planning
Council
private list <eclipse.org-planning-council@xxxxxxxxxxx>,
Date:
07/17/2015 10:41 PM
Subject:
Re:
[eclipse.org-planning-council]
Next meeting, and some items to decide before next meeting
Sent by:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
Do the EPP packages even have a
version?
I guess they do but no one knows it as that. It’s Mars.
And it has nothing to do with the
Platform
version. End users know nothing about the platform. Only the
package they
download and use.
But I’m not sure I like “minor
release”.
I agree with Ed that this implies much more than it actually
should. A
relatively few features have minor releases in one of these.
As I’ve made clear in the past, I
don’t
like “service release” either, because the number of features
releasing
minor releases is usually non-zero. It’s also misleading.
I’ve started calling the
September
release Mars.1. And Feb Mars.2 I guess. Drop the SR notation. It
then looks
like a minor release without having to actually call it that.
This is something we could
probably
carry on as we move to faster releases. Speaking of which,
dropping the
SR term is a big step towards that. The rest is just playing
with the schedule/cadence.
What I’m really looking for is a change in culture which David
correctly
points out as the problem, I.e., people don’t know they already
have the
mechanism to do new features in the “dot releases". (hmm, that
just
rolled out, maybe that’s a good term, dot releases). We just
need to make
it clear they can.
Doug.
From: <eclipse.org-planning-council-bounces@xxxxxxxxxxx>
on behalf of Ed Merks <ed.merks@xxxxxxxxx>
Reply-To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Date: Friday, July 17, 2015 at 11:17 PM
To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Subject: Re: [eclipse.org-planning-council] Next meeting,
and some
items to decide before next meeting
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
http://about.me/maxandersen
On 17 Jul 2015, at 13:50, David M Williams <david_williams@xxxxxxxxxx>
wrote:
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.
_______________________________________________
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.
_______________________________________________
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.
|
