Bugzilla – Full Text Bug Listing
| Summary: | Ganymede maintenance releases should not use 'Winter', 'Spring' | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Cross-Project | Assignee: | Cross-Project issues <cross-project.inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bfitzpat, bjorn.freeman-benson, blueser, bugs.eclipse.org, contact, dgaff.eclipse, Ed.Merks, Markus.Milleder, mknauer, mober.at+eclipse, nboldt, oisin.hurley, pelder.eclipse, philippe_mulet, pnehrer, richard.gronback, steffen.pingel, valentinbaciu, who, wmitsuda |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
David Williams
And ... my response is ... Finally ... some people from the southern hemisphere complain! This has been discussed before, and since I'm responsible for the original 'winter', 'spring', thought I'd a) apologize for such a narrow minded Northern Hemisphere bias, and b) explain some history. When ever this has come up for discussion before (usually prompted by Ian, I believe :) ), there was never any clear alternative, as some wanted to use numbers, some wanted to avoid numbers at all costs, since there is really nothing numeric about it. And ... the discussions would often end with something like ... "well, has anyone in the southern hemisphere actually complained about this? Maybe that bias and mistake are so common they are just accustom to it and it's no big deal". So, it's good to have it confirmed it does matter from a "native" Southerner :) And, I agree with the Month usage. But ... I think this should be only for the maintenance versions ... that "Ganymede June" would be just "Ganymede". The formerly called "winter maintenance" would be "Ganymede September maintenace", etc. Sound ok? Vote early, vote often. "Ganymede September Maintenance Release" works for me. (In reply to comment #2) > "Ganymede September Maintenance Release" works for me. +1 (In reply to comment #1) How about a medical metaphor? "Ganymede Booster" and "Ganymede Check-Up" in that order? (In reply to comment #4) > (In reply to comment #1) > How about a medical metaphor? "Ganymede Booster" and "Ganymede Check-Up" in > that order? Hehe, I like that idea, esp. since it's alphabetical (B then C). Then again, it might imply the June release is sick...? I'd also vote for something more "train-centric", like: * Ganymede, Ganymede Mark Twain, Ganymede End Train Based on the time honored traditional of alpha and beta releases, I propose: Ganymede, Ganymede Omicron (middle of the Greek alphabet), Ganymede Omega (end of the alphabet) There's always this: Ganymede Ganymede Reloaded Ganymede Revolutions http://whatisthematrix.warnerbros.com/ Just kidding. :-) How about the fairly commonly used service pack SP1, SP2 or service release SR1, SR2. Hopefully they are not trademarks or anything... I like this except that some projects do more frequent releases than Fall and Spring (sorry), so SP1 and SP2 could be confusing. I'm partial to the Greek letter thing. They go so well with the Jupiter Moon theme. If alpha and beta are pre-release things, then doesn't it follow nicely that gamma and delta are post release things? (In reply to comment #1) > And ... my response is ... > > Finally ... some people from the southern hemisphere complain! =) Actually, this has been bothering me for a while already, but I kept putting it off... ;-) (I'm the one who complained on bug 224729 about the use of season names) > This has been discussed before, and since I'm responsible for the original > 'winter', 'spring', thought I'd a) apologize for such a narrow minded Northern > Hemisphere bias, and b) explain some history. From a native southerner (Brazil), apologies are officially accepted =) > When ever this has come up for discussion before (usually prompted by Ian, I > believe :) ), there was never any clear alternative, as some wanted to use > numbers, some wanted to avoid numbers at all costs, since there is really > nothing numeric about it. And ... the discussions would often end with > something like ... "well, has anyone in the southern hemisphere actually > complained about this? Maybe that bias and mistake are so common they are just > accustom to it and it's no big deal". > > So, it's good to have it confirmed it does matter from a "native" Southerner :) =) > And, I agree with the Month usage. But ... I think this should be only for the > maintenance versions ... that "Ganymede June" would be just "Ganymede". > The formerly called "winter maintenance" would be "Ganymede September > maintenace", etc. Sound ok? Sounds just fine to me. Just curious: how is the tarball going to be named? "eclipse-java-ganymede-september-linux-gtk.tar.gz"? Thks for understanding this is an issue, even though it might sound silly at first =) (In reply to comment #10) > I'm partial to the Greek letter thing. If alpha and beta are pre-release things, then doesn't it follow nicely that gamma and delta are post release things? Based on that logic, wouldn't Gamma be the actual release? +1 for Gany Delta and Gany Epsilon, and not just because Gany Gamma sounds like some form of children's entertainment. :P (I still like Gany Twain and Gany Train.) +1 for *not* using the old scheme (fall, winter, spring, etc.) +1 for 'Ganymede September Release' as this implies when this release will be available. I assume that *if* we use unusual greek letters or other new acronyms we will have to explain that to the users again and again. Using the name of a month is easy to understand and (partly) follows the tradition of the Ubuntu naming scheme (e.g. 2007.10). (In reply to comment #13) > +1 for *not* using the old scheme (fall, winter, spring, etc.) > > +1 for 'Ganymede September Release' as this implies when this release will be > available. > > > I assume that *if* we use unusual greek letters or other new acronyms we will > have to explain that to the users again and again. Using the name of a month is > easy to understand and (partly) follows the tradition of the Ubuntu naming > scheme (e.g. 2007.10). > 100% agreed. Why complicate something that can (and should) be simple and straightforward? I was assuming the other options were jokes, but since it appears they're not, I think I'd better vote ;-) +1 for 'Ganymede September Release' (In reply to comment #13) > I assume that *if* we use unusual greek letters or other new acronyms we will > have to explain that to the users again and again. My suggestion (comment #6) was a joke - obviously Omicron and Omega would be a bad idea :-) In reality, I agree with the majority here: month names are the best choice. (I guess I should have included a smiley.) The month thing seems OK, but I find it it a bit weird that we have the "Ganymede" release and then will follow up with month releases, because it's not clear from "Ganymede September Release" that this is an update to the June release. To address that we could call the first one the "Ganymede June Release", but that sounds a bit long. (In reply to comment #9) > I like this except that some projects do more frequent releases than Fall and > Spring (sorry), so SP1 and SP2 could be confusing. While I think it's important for projects make space for more frequent updates, I thought that most projects did this via version numbers (e.g. Eclipse 3.3.1, BIRT 2.1.3)? If there isn't a problem of clashing, I think it would be good to consider the names to make the "update/refresh" aspect explicit, like SP1. Assuming that the SP1 notation has too close an association with Microsoft, so far the best candidates for that seems to be: * Ganymede (original June release) * Ganymede Update 1 * Ganymede Update 2 It's a bit boring, but I think that the "Ganymede" part of the name is supposed to be what's exciting, and the rest of the label should just be clear about what the release is. (In reply to comment #16) > The month thing seems OK, but I find it it a bit weird that we have the <snip> > consider the names to make the "update/refresh" aspect explicit, like SP1. > Assuming that the SP1 notation has too close an association with Microsoft, so > far the best candidates for that seems to be: > * Ganymede (original June release) > * Ganymede Update 1 > * Ganymede Update 2 So maybe * Ganymede (original June release) * Ganymede September Update * Ganymede February Update However, the name "Update" to me implies the need to have the base version before applying the update, so I'm slightly in favor of "Release". My $0.02, I think simply "Update 1, Update 2", etc, is clearer. It may not be obvious to users that September comes before February in the Eclipse world. -1 for anything with a month in it, unless it also includes the year, eg., 08.09 or even "Ganymede September 2008 Release", a la ubuntu. Assuming that you can in fact move from Ganymede to Ganymede Update or Update 2 using nothing but p2 / Install Manager (ie., no extra downloading required) then "Update" makes sense. If your install is done some other way (eg., multiuser linux box, where you can't replace the base Eclipse because it's installed in a central location to which you don't have write perms), then Update becomes a bit of a misnomer. -1 for use of "Update", per comment 17 Per comment 9, I don't think there's any danger of confusion in terms of the versions of the individual projects that go into the SRs. If a project moves from .0 to .3 before SR1 comes out, that's fine -- nowhere is it stated that SR1 will require .1 releases from all the projects, and in many cases, projects are still on .0 or .1 for their SR2, er., Winter Maintenance contribution. (Unless of course the projects themselves use "SR" notation in their releases. Does anyone do that?) So per suggestion in comment 8, -1 for "SP" because of its negative Microsoft connotations +1 for Ganymede, Ganymede SR1, Ganymede SR2 (SR = Service Release) (or Ganymede, Ganymede MR1, Ganymede MR2 (MR = Maintenance Release), if SR is trademarked / copywritten / used by individual projects / has bad connotations for anyone) I'm changing my vote. I like Nick's suggestion of "Service Release". -1 for Maintenance Release x. MR2 (in french) is a less than positive acronym, as Toyota found out when it tried to sell a car with this model number in Quebec. +1 for Service Release (SR1, SR2). But then, maybe some other polyglot will point out that this is a rude in some language. +1 for "Service Release" SR1, SR2 +1 for Update 1, Update 2. +1 for Update 1, Update 2 (John's comment#18 sums it up, and "update" is a commonly used short form for "updated release") + 0.666667 for SR1, SR2 ("update" is more self-evident than "SR", which is hard to find a definition for if you don't know what it means) I have a hard time counting all the +1's, etc., here (that is, to "see" the consensus) plus, technically speaking, I think the Planning Council is the Eclipse body in charge of these names, so I will ask the Planning Council to make the final vote based on all this good discussion and suggestions. Below I list what I think are the 3 viable alternatives, from all those discussed. Planning Council members: Please indicate your top _two_ votes, by letter, A. B., or C, ... in order of "first choice", "second choice", ... that way, if there is no majority winner, we will have a "run off" vote automatically built in, by eliminating the least voted on choice, and then taking the majority of what remains. (it's supposed to be a fairer way of voting .. recently piloted in North Carolina :) ). Who are the Planning council members anyway? See http://www.eclipse.org/org/foundation/council.php Let's say the "cut off" for voting is Monday 5 PM Eastern ... that is a bit short, but I think we should have this finalized before we release, just in case it effects written materials or discussions that occur around the release. = = = = = Lettered alternatives below are listed with: Full formal name Short Name Name for EPP zip files, etc. (Note, the names for EPP zip files, etc, are just an illustrative suggestion ... EPP, or any project, can decide themselves ... I just listed them here for illustration, in case it effects considerations for the name. A. Ganymede <Month> <Year> Maintenance Release Ganymede <Month> Maintenance Release ...-ganymede- .... -YYYYMM-... B. Ganymede Service Release <i> Ganymede SR1,SR2, etc. ...-ganymede- .... -SR<i>-... C. Ganymede Update Release <i> Ganymede Update <i> ...-ganymede- .... -UR<i>-... = = = = = Much thanks for bringing up the original issue, and everyone's valuable discussions. B. A. B A B, then A B A B. C. Although I think (B) is the best option, the golfer in me responds to (C) because G.U.R. (Ganymede Update Release) really means Ground Under Repair, which is just so appropriate :) +1 for month names a. b. B. C. I'd vote
a then b
But, "B" would still be the most popular, getting a majority (6 of 9) without even a runoff count ... and, I should say, that's a majority of council members that voted. I guess the others, by their silence, are saying they don't care which of the three we go with.
So ... Service Release it is!
Ganymede Service Release <i>
Ganymede SR1,SR2, etc.
...-ganymede- .... -SR<i>-...
And apologies in advance to our southern hemisphere colleagues, but still find myself sometimes saying "Service Release 1 in the fall". I'm sure I'll adjust eventually. :)
Much thanks to everyone for raising the issue and all the thoughtful and careful discussion.
Hi David, as the OP for bug 224729 I thank you and all the other council members for taking this seriously, IMHO the SRx naming scheme is much more effective than "winter", "fall" etc. Regards, Andre |