Bugzilla – Full Text Bug Listing
| Summary: | More consistency when referring to eclipse versions | ||
|---|---|---|---|
| Product: | Community | Reporter: | Wayne Beaton <wayne.beaton> |
| Component: | Cross-Project | Assignee: | Wayne Beaton <wayne.beaton> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, david_williams, igor, john.arthorne, mknauer, mober.at+eclipse, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
|
Description
Wayne Beaton
The releases are named rather than numbered because there are many multiple projects involved in the release, each has its own release scheduled and version numbering scheme, and it is generally incorrect to equate the entire release with the numbering scheme of any single project. However, the number most often associated with the release is that of the Eclipse project. We do this ourselves on the package download page, as well as in some project pages. In my experience, people in the community connect a specific version of the Eclipse project with each named release train. While this may be considered technically incorrect, I'm not sure if we're serving the community by trying to keep these separate. Or, given that the package download page refers to "Eclipse Indigo (3.7.1) Packages", can we reasonably state that we've already given up on trying to keep these separate and should try to more consistently propagate this numbering scheme? 3.8/4.2 juno is going to be even more confusing. Maybe we should consider replacing "(3.7.1)" on the download page with "SR1", and removing "(4.2)" from the development tab (http://www.eclipse.org/downloads/index-developer.php). That way we would achieve some level of consistency. Apart from that I don't see any chance to change the situation because even the Classic download contains features in many different versions. Debian, Ubuntu, Microsoft, ... they all use logical names for the operating systems, why should Eclipse be different? "Eclipse Classic 4.2 M2" or "Eclipse Classic 3.7.1" would be the name of *one* package and nothing else. In that case it would be even possible to add another "Eclipse Classic 3.8 M2" to the list of packages. I'm sure we have had this discussion many times before, but can't find a pointer off-hand. I think it's a valid point of confusion for the user community that is not closely following the project, that they don't know the code names and how they related to each other and to when they came out. I know for other software I couldn't tell you off the top of my head what year Hardy Heron or Snow Leopard came out, etc. Unfortunately this year, even throwing in the platform version number doesn't help. If last year was 3.7 and this year is 4.2, there could be a lot of confused users looking for the 3.8, 3.9, 4.0, and 4.1 versions of the release train. Another option is to use the year along with the code name (Juno/2012, Indigo/2011, etc). Or Year.Month following the Ubuntu model. For Juno that would be: 12.06, 12.09, and 13.02. Comment #0 specifically talks about Help > About . I'm +1 for adding the release train name into Help > About, in addition to the Platform version (eg 3.7.1) and the build ID. We already have the release train name in the splash screen, so adding it into Help > About makes sense. For reference, here's what our commercial product's about looks like: Wind River Workbench Version: 3.3.2 20111007-1004 [...] Powered by Eclipse Indigo Version: 3.7.1 M20110909-1335 As additional input for the discussion: All EPP packages have the same (or a very similar) about dialog, e.g. the RCP/RAP package contains this text: %< -------------------------------------- Eclipse for RCP and RAP Developers Version: Indigo Service Release 1 Build id: 20110916-0149 %< -------------------------------------- Thanks Markus, this looks good.
Though I personally like the Eclipse Platform version as additional info
("Powered by Eclipse 3.7.1 Indigo") sine the plain build ID is meaningless to most end users.
Especially in case we should have both "Eclipse 3.8 Juno" and "Eclipse 4.2 Juno" packages this year, the extra Eclipse Platform Version would help.
(In reply to comment #7) > Thanks Markus, this looks good. > Though I personally like the Eclipse Platform version as additional info > ("Powered by Eclipse 3.7.1 Indigo") sine the plain build ID is meaningless to > most end users. > > Especially in case we should have both "Eclipse 3.8 Juno" and "Eclipse 4.2 > Juno" packages this year, the extra Eclipse Platform Version would help. I was under the impression that the planning council agreed to only have Eclipse 4.2 based Juno EPPs. Or did you mean something else by "packages this year"? (In reply to comment #8) > (In reply to comment #7) > > Especially in case we should have both "Eclipse 3.8 Juno" and "Eclipse 4.2 > > Juno" packages this year, the extra Eclipse Platform Version would help. > > I was under the impression that the planning council agreed to only have > Eclipse 4.2 based Juno EPPs. Or did you mean something else by "packages this > year"? Yes, I can confirm... EPP agreed to create all packages based on Eclipse 4.2 - see http://www.eclipse.org/downloads/index-developer.php for the Juno development packages. (In reply to comment #9) > Yes, I can confirm... EPP agreed to create all packages based on Eclipse 4.2 - Sure, the PC and committers know this ... but will all the users / adopters know this? Especially when there will be other (commercial) products on Juno 3.8 ? (In reply to comment #4) > Another option is to use the year along with the code name (Juno/2012, > Indigo/2011, etc). Or Year.Month following the Ubuntu model. For Juno that > would be: 12.06, 12.09, and 13.02. I think this is the correct direction. Another variant is to go with simple integer numbers. For example, we could call the next release Eclipse Juno 6 because it is the 6th simultaneous release.(In reply to comment #10) > (In reply to comment #9) > > Yes, I can confirm... EPP agreed to create all packages based on Eclipse 4.2 - > > Sure, the PC and committers know this ... but will all the users / adopters > know this? Especially when there will be other (commercial) products on Juno > 3.8 ? Can we really call the Eclipse Project version 3.8 a Juno release? The few bundles from the Eclipse project that differentiate Eclipse Project version 3.8 from version 4.2 are only being contributed to Juno in their 4.2 versions. If that is the case I don't really think the Eclipse Project version 3.8 is a part of the Juno release. (In reply to comment #11) > Can we really call the Eclipse Project version 3.8 a Juno release? The few > bundles from the Eclipse project that differentiate Eclipse Project version 3.8 > from version 4.2 are only being contributed to Juno in their 4.2 versions. If > that is the case I don't really think the Eclipse Project version 3.8 is a part > of the Juno release. Technically Eclipse Platform 3.8 will ship simultaneously with Juno. It will not be in the release train common repository or EPP packages, but it will be released at the same time. This is much like how Platform 4.1 was shipped simultaneously with Indigo. No matter what we call it, there is bound to be confusion. We can reinforce this in our branding though... Splash screen and Help->About for 4.2 could reference Juno but not for 3.8. To focus on comment 0, consistency is good, but, not sure the answer is to include the platform number along with the Simultaneous Release name. My guess is if we did, we'd just "move" the discussion to a different level ... I know for a long time, people have said "why isn't WTP the same version number as the platform, that's be so much less confusing" ... and, I know some projects have deliberately "jumped" levels, trying to say in sync with the platform version number (contrary to versioning guidelines). While I don't know what the answer is, I mostly wanted to cross-reference here in this bug, some of the many previous discussions, such as those documented in bug 287707. Comment 0 does provide the use case they are trying to solve "... useful when reading a 3rd party addons instructions for installing" so ... not sure if those instructions are poor? Should we provide good examples, or better "instructions for instructions"? Another source of help might be to better link from some general "download" pages to tables such as http://wiki.eclipse.org/Simultaneous_Release This, to me, is similar to a table for Ubuntu I sometimes needs to check to see what number goes with what name https://wiki.ubuntu.com/Releases And, even with that table, I still get confused about "what kernel is in which version of Ubuntu X?" "Which version of GTK?" etc. (And, even those versions can vary from one install or "service release" to the next.) In other words, its a tough problem that I do not know how to solve, other than to encourage consistency, and encourage better instructions for 3rd party add-ons. For example, instructions normally should say more than just version name or number, but give a URL from where to install ... which would disambiguate a lot of cases. Hope these comments and "cross-references" help. I'll assign to Wayne just to reduce "spam" mail being sent to everyone but not sure who (if anyone) is responsible for resolving this issue. Plus, thought I'd point out this table: This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. In the Platform / SDK product we now show both: Version: Neon (4.6) This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. (In reply to Dani Megert from comment #16) > In the Platform / SDK product we now show both: > > Version: Neon (4.6) I'm seeing a similar pattern in the packages. I believe that this means that we're done. I'll mark this as fixed with an understanding that somebody will reopen if I've made a horrible, horrible mistake. |