Why it’s time to kill the Eclipse release names:Neon, Oxygen, etc


I thought I’d heard all the arguments for why developers choose IntelliJ IDEA over Eclipse IDE, but this was a new one. I was at a meet-up with lots of Java developers, and inevitably the conversation went to the topic of preferred Java IDE. One developer raised the point ‘I never understand the different versions of Eclipse, you know, Luna, Mars, Neon – what does what, which is the Java one I should download? With IntelliJ it’s just IntelliJ community or ultimate,I know what to get.’ I had to stop myself from launching into a let-me-explain-it’s-simple-and-alphabetic explanation and instead just listen and look around to see others were nodding along in agreement with the speaker.

Not long after that I was reading this article: Kill extra brand names to make your open source project more powerful by Chris Grams. In the article, Grams talks about the ‘mental brand tax‘  incurred when projects have additional brand names users are expected to understand. This was the name for what the developers were expressing. As Grams explains “…having a bunch of different brand names can be exclusionary to those who do not have the time to figure out what they all are and what they all do.” This sounded like those developers who are busy solving their problems and keeping pace with the fast developments in software.

From my corporate days, engineering often had a working project name. For example, there were the projects named after US state names: ‘New Jersey’, ‘California’, etc. However, when it came to release, these internal names were always scrubbed out by the product marketing department and never referred to from the user perspective. In those cases it was easy to see how the project names could cause real confusion out in the world.

In Eclipse, the names are part of the development flow. It’s a nice way for the community to get together to choose them and it is a common language for us as Eclipse developers to use. Often we don’t differentiate between developer-users and developer-extenders. We expect all users to know they are alphabetic and follow a similar theme. But if you think about it isn’t that just another level of abstraction put onto Eclipse versioning? Should these names really be going out to the Eclipse users? Should we expect our users to know Neon is the same as Eclipse 4.6 which is the same as the version that was released in 2016? Ditto for all previous versions? (And that is before we get into the different flavours of the IDE e.g. Java, C/C++, etc).

So what could we use instead? I don’t have all the answers, but want to kick off the conversation with a proposal. As Grams summarizes “Sometimes the most powerful naming strategy is an un-naming strategy”. What if we did that? The Eclipse simultaneous release is reliably once a year. How about we use the year it comes out to version it. So this year, Neon would be Eclipse IDE 2016, Oxygen becomes Eclipse IDE 2017 and so on. The added benefit to users is that it becomes immediately obvious how old previous versions are. So instead of ‘Are you going to fix my bug in Luna?‘ someone might ask ‘Are you going to fix my bug in Eclipse.2014?‘ It might be more straightforward for them to see they are already 2-3 years behind the latest release.

As we, as a community, move towards thinking and treating Eclipse more as a product, this is a change that could be well worth the effort. As Grams notes:Just because you have a weak confederation of unsupported brands today doesn’t mean you can’t change. Try killing some brand names, replacing them with descriptors, and channel that power back into your core brand.”

43 Replies to “Why it’s time to kill the Eclipse release names:Neon, Oxygen, etc”

  1. If a developer is not able to understand the Mars, Neon, etc naming scheme maybe they should stop being developers. According tot his logic, these cool devs would be confused beyond hope if they had to use Ubuntu Linux.
    Looks like they decided beforehand that Intellij was cooler anyway, regardless of the current Eclipse naming scheme…
    Never underestimate the ability of Intellij fans to literally shit on Eclipse invoking whatever minuscule reason cross their mind at the time.

    1. Ubuntu is primarily marketed using it’s Version Codes instead of the animal names, e.g. http://www.ubuntu.com/download/desktop

      I see myself as an informed developer in the eclipse space and i don’t have any Problem with the naming scheme. But to my colleagues we used the internal versioning scheme 4.6 when talking about issues.

    2. I agree with the article. Although I am a long time Eclipse user I never undestood the need of the release train naming. It was always confusing. Just get rid of it. You might attract a few of those IntelliJ IDEA devs back.

    3. Developers can understand the difference – no worries. This article was not about that, but about perception in general. Why to bother with confusing names and create mapping: Brand YearOfRelease?
      I fully agree with author of this article – even if I’m not going to switch to IntelliXYZ, NetBeans, etc.

    4. Bob, I am a developer with 35+ years of experience. I Just wanted to see today whether I should update my Mars.2 on one of the several projects that I work on, to a newer version and what that version would be. Couldn’t find an answer in the 2 min that I had time for this specific check. So, why bother with stupid, uninformative, bogus names that make it impossible to compare releases in a meaningful way without knowing all the gory details of Eclipse IDE evolution over the last decade? Why should I care? My job is to write code for my customer, not to evaluate Eclipse versions, or track their history. Why make it a research when all you want is to get an IDE installed as quickly as possible and focus on your actual work. And, BTW, while I do use Eclipse as my primary IDE for a variety of reasons, it does suck as a software product – crashes pretty much every other day with normal use. So, yes, there are IDEs out there that are better.

  2. I like this blog post, because you are thinking out the box and you trigger a debate with solid arguments.

    I like the Release Train code name and I do not think that we need to remove them. I think the branding is getting better over the years (custom splash screen, video, release material …)

    I agree with you on those points:
    1/ on the website (the screenshot), we need indicate the differences between the releases:
    – A current stable release (Mars at the moment )
    – A “in development” release (Neon at the moment)
    – And legacy releases

    2/ we need to associate somewhere (maybe on the splash screen) the release year: 2016 for Neon. This way our users might better understand that they have a 2 years old release (e.g. Luna)

    As for the IntelliJ comparison: we need to better defend the Eclipse IDE. We have a lot of great features/news:
    – Progress made on existing problems
    – Innovative project:
    o Oomph
    o Code recommenders
    o …
    – The new direction of the Friend of Eclipse Program is also something very good.

    The conference from M. Barbero at Devoxx France was great. But we need more of those conferences.
    Maybe we should create a group/project to exchange information and material and encourage participation everywhere we can.

    We see a lot of great topics at the EclipseCon, but my feeling is that we are not enough open towards the rest of the java community. This way the circle of convinced Eclipse IDE users can grow.

    One last aspect that is really important for me:
    Eclipse IDE is free and open-source. Contributions are welcomed in a lot of subprojects (this is something that was improved in the last years). Being able to fix/contribute something inside an IDE is something I really like.

    1. Mikaël Barbero’s presentation at Devoxx sounds like it was great, I really like the sentiment ‘The Force Reawakens’ – it definitely feels like that is the case for Eclipse, in which case perhaps we will see some of your suggestions acted on in the upcoming months .

  3. +1.

    I have attended few democamps together and there was always a quiz+goodies to match the code name with the number version. ‘Neon’ can be a code name for the projects that are participating in the release train and 4.* is for adopters (extenders, users and other humans).

    We have a similar confusion within our organisation itself – what should be the third qualifier for the plug-ins? Is it the project or product name? We typically do not have a product name when the project starts and management wakes up at the end and says that we should have the product name in the source code. The trouble we had is an inspiration for a movie that will bag the next Oscar 2017!

    PS: Oscar ceremonies do not have code name.

  4. I think you really missed the point. Not the codenames are the problem but the name eclipse for the IDE. In the beginning eclipse was the name of a very good java IDE and everything was good, but then more and more projects which have nothing to do with a java IDE adopt the brand name eclipse. So when you search the web for eclipse you get many hits for other projects under the umbrella of the eclipse foundation which have nothing to do with your java IDE. So i think eclipse needs to find a new name for the IDE so that it is much easier for people to find out if an information the find on the internet is related to their favorite IDE or to another eclipse project.

    1. There is more than one way to interpret the article, and in this case it is more of applying the concepts, especially the ‘mental tax’. What you describe is the literal interpretation of the article, which is also quite interesting. Especially when there are projects like Eclipse Che which piggyback on the brand created by Eclipse Java IDE, but it is not necessarily obvious to the casual observer that the technologies (with the exception of Java indexer) are vastly different.

  5. +1 and of course a lot of people will be upset and defend the release names. But thinking back of old names it is really not clear what version matches what name. Helios, was that 3.5 or 3.7? Who knows? And why should we care? Plain numbering is very clear. Anyhow, great to get this discussion going – status quo is not the answer.

    1. It’s telling when you wonder if Helios was 3.5 or 3.7 and not whether 3.7 was Helios or Indigo.

  6. My thoughts:

    1) If names are universally used(that is, everybody used “Neon” instead of sometimes using “Neon” and sometimes using 4.6), there is little difference between both schemas. After all, I get the same information from “this project was developed for Indigo and the current release is Neon” that from “this project was developed for 3.7 and the current release is 4.6).

    2) If you want to get extra information from the version system, use a different approach. Release year gives only a little information (after all, I am developing with Eclipse I should at least approximately if the latest is “M or N” or “H or I”). What could be interested would be a MAJOR (and I mean it, that only changes when there are really radical changes, maybe once in a decade) version number, the number of JDK supported as minor version number, and the year of release as release number. So 1.8.16 would give all the information I need or want.

  7. I’ve got mixed feelings on this myself. It’s cool to have a bolder, more in the face identifier of the version than say 4.6. In reality though, Eclipse Mars and Eclipse Neon sound like they two entirely different projects/products rather than two versions of the same IDE. On the other hand ‘Eclipse IDE 2017’ is way too business-y and rather dull, but at the same time actually placing the year/release date in a prominently visible location is important for identification purposes.

    Arguments about the ‘best’ or ‘most powerful’ naming strategy are not productive. It’s good to think about it once in a while in case something changes that renders the current strategy poor, but rather pointless to get too far on the hype train about some new/better way of doing things if the current one is sufficient.

    Equating names only to major revisions would help.

  8. I am supposed to update one of our documents and tell the users how the can get Eclipse 4.4.2 or higher. I am currently looking for a page that shows the version number to fantasy name mapping. No luck so far.

    The release names and their relationship to the release numbers is completely obscured. This is bad because, how am I supposed to figure out which release I am using, from the “About” pages. They show the version numbers and not the release names.

    I think the problem is not having multiple releases, the problem is that the relationship between the release name and the version is oscured.

    1. It’s not that devs can’t figure it out, it’s that devs would rather not waste time figuring it out. Case in point, I’m relatively new to Eclipse. I have dabbled with it in the past and hated it but now I need it. I have just wasted an hour digging around trying to find the latest release and reading articles on Eclipse release naming. The download page lists Eclipse ‘Neon’, well what the hell is that I ask, I just want the latest version of Eclipse ‘normal’. Yes, I know the information is available but the whole drama would have been unnecessary had a normal versioning system been used.

  9. As a developer who is drawn back to java every 5 years or so (even managed a dev org for a while 15 years ago) the Eclipse naming scheme is bizarre and confusing. If you go to the current download page https://eclipse.org/downloads/ there is no clear indication of which thing is actually the IDE. Making release names (luna, neon, mars, etc) at the same level as project names (che, equinox, concierge…) is just madness.

  10. The whole naming scheme makes no sense if it is absolutely distinct from the versioning scheme.
    On lots of other open source (and lots of closed source) projects there are release names, but in a sane manner. Like “FooBarBayProgram 12.3.8 a.k.a. Bumblebee”. This way anybody visiting the webpage can immediately get the information which name corresponds to which name.
    Now the Eclipse About page lists the nickname and the version as well, this should be used on the webpage.

    And the argument to question the competence of a developer who finds it hard to match the nicknames to versions means ignoring other peoples priorities/schedules.
    If any user has to make a bonus google search to find out the version, then the developers can think of this as they wasted at least a minute of the user’s time. And there are lots of users and not everybody is in the Eclipse versioning day-and-night.

    Merely the fact that the version-nickname table is not included on the Eclipse website is really mad!

  11. Thanks for this article! Saved me some time! I’m new to eclipse and totally confused by the naming! If you don’t know about the naming already, the download page is mighty confusing, I want “eclipse” and what I see on the page is: sirius, neon, che, jetty, orion, equinox, …

    Sure I guess most developers are smart enough to figure it out, but why would you want to annoy newcomers to eclipse even before they start using it by making them jump through hoops like that? Look at any other OSS project, almost always there is a big fat button screaming “Latest (vanilla) Version here!”

  12. Hear, hear. Even as a long-time Eclipse use the whole code-name thing has been an annoyance. Simple versioning schemes like v4.7.3 give us a lot more information than a code name! For example, which is newer Mars or Neon versus v4.6 or v4.7? It’s also easy to differentiate bug fix releases from major releases. I’m not a fan of adding a separate year-based numbering on top of the simple versions that Eclipse already have if only they would just use them!

  13. Eclipse.org needs to improve its messaging act or else dropping the names or keeping them won’t matter at all. Will just knowing that a 9.1.1 exists help me know that it’s not the latest? Obviously not. Messaging has to be done and messaging opportunities are being missed. Let me try to mention some.

    .If you go to the eclipse.org page, there is not one shred of evidence that eclipse.org is the source of Eclipse Neon or the upcoming Eclipse Oxygen. So the actual home page of the project is not being maintained in a way that helps users learn which release to use.

    It just so happens that I found this blog article by searching with “Eclipse Oxygen” to try to find out what would make me install Eclipse Oxygen.0 on my newly acquired laptop vs Eclipse Neon.3 which is on my old laptop. I looked at https://projects.eclipse.org/releases/oxygen and it just has a roster. This has no context to it. I think it’s possible the customers/haters who can’t handle Mars vs Neon actually could be suffering more from this lack of messaging rather than from an unexpected inability to comprehend the order of the alphabet. Another thing is that the names used to be heavenly bodies and now they are gases. Android has reached the letter N while still using desserts which I think does help the power users track the letters. Now another thing is, that Android benefits from a massive amount of press, practically unescapable if you follow the (wrong?) news sources.

  14. Personally, I love the way Eclipse name their releases! It ‘s just sound…..Fresh and interesting :v

  15. It’s a mess. Could also explain why some of my plugins keep getting disabled/broken during updates. Running a clean instance Oxygen (not a Neon upgrade), ran a basic update yesterday, from no where Neon update repo has been added and enabled, Devstyle Dark Theme doesn’t work, EGit Integration now broken, I’m wondering if even plugin devs struggle with versioning and compatibility checking… smh

  16. whoah this blog is magnificent i really like studying your
    articles. Stay up the good work! You recognize, lots
    of individuals are hunting around for this
    information, you could help them greatly.

  17. As Grams explains “…having a bunch of different brand names can be exclusionary to those who do not have the time to figure out what they all are and what they all do.” This sounded like those developers who are busy solving their problems and keeping pace with the fast developments in software.

    OH, please. If you can handle chasing down all the @#$%$ magic handwaves to get any freaking actual project going in this Era of Absolute Kludges (display, debugging, database, whatever, all add-ons needing setting changes… Maven/Gradle. GIT, Jenkins, TestNG), the notion that you’re too stupid to figure out what NAMED SOFTWARE VERSION you need to have is ridiculous.

  18. I’m coming back to Java from C# (and to Eclipse from IntelliJ) and I had to GOOGLE what the hell was Oxygen, as I assumed it was a different build of Eclipse all together. Didn’t even occur to me it’s just a version name. And I couldn’t even find what it was until I stumbled onto this article that’s THREE YEARS OLD.

  19. BORING – took away one of the fun things – if a person can’t understand alphabetic order maybe they should be in some other line of work. I mean, did they pass calculus but can’t understand alphabetic order? Really? This career used to be fun and put out very high quality work. Now – not so anymore.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: