fwiw, I like the format:
Mars
Mars.1
Mars.2
Sure it is geeky and subtle but our community is full of geeks and
over time it will be obvious, not subtle.
My 2 cents....
Ian
On 20/07/2015 11:47 AM, Neil Hauge
wrote:
If "Mars 1" is potentially confusing and "Mars.1" too subtle (code
name combined with version syntax), how about simply:
Mars
Mars Update 1 short version - "Mars u1"
Mars Update 2 short version - "Mars u2"
"Update" is a fairly generic term. Just another suggestion to
consider. I think given our audience "Mars.1/Mars.2" is probably
reasonable as well, although perhaps a bit awkward.
Neil
On 7/20/2015 11:20 AM, Daniel Megert
wrote:
This is really to
subtle/geekish ;-)
Dani
From: Doug Schaefer <dschaefer@xxxxxxx>
To: Eclipse Planning Council private
list <eclipse.org-planning-council@xxxxxxxxxxx>
Date: 20.07.2015 17:18
Subject:
Re:
[eclipse.org-planning-council] Next meeting, and some items to
decide before next meeting
Sent by:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
That’s why I proposed Mars.1, not
Mars 1. The dot implies an increment on the Mars release.
From: <eclipse.org-planning-council-bounces@xxxxxxxxxxx> on behalf of Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
Reply-To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Date: Monday, July 20, 2015 at 11:14 AM
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
+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?
Cheers,
Ian
On Mon, Jul 20, 2015 at 9:46 AM,
Daniel Megert <daniel_megert@xxxxxxxxxx> wrote:
+1. We shouldn't abuse the
terms and only increase when appropriate.
Dani
From: Ed Merks
<ed.merks@xxxxxxxxx>
To: eclipse.org-planning-council@xxxxxxxxxxx
Date: 18.07.2015
05:18
Subject: Re:
[eclipse.org-planning-council] Next meeting, and some items to
decide before next meeting
Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx
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@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.
_______________________________________________
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.
--
R. Ian Bull | EclipseSource
Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________
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.
_______________________________________________
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.
--
Ian Skerrett
VP of Marketing
Eclipse Foundation
(m) 613-240-7210
(o) 613-224-9461 ext 227
(t) @ianskerrett
|