

So this year, Neon would be Eclipse IDE 2016, Oxygen becomes Eclipse IDE 2017 and so on. How about we use the year it comes out to version it. What if we did that? The Eclipse simultaneous release is reliably once a year. As Grams summarizes “ Sometimes the most powerful naming strategy is an un-naming strategy”. So what could we use instead? I don’t have all the answers, but want to kick off the conversation with a proposal. 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. We expect all users to know they are alphabetic and follow a similar theme. Often we don’t differentiate between developer-users and developer-extenders. 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.

In Eclipse, the names are part of the development flow.

In those cases it was easy to see how the project names could cause real confusion out in the world. 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. For example, there were the projects named after US state names: ‘New Jersey’, ‘California’, etc. 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.įrom my corporate days, engineering often had a working project name. This was the name for what the developers were expressing. In the article, Grams talks about the ‘ mental brand tax‘ incurred when projects have additional brand names users are expected to understand. Not long after that I was reading this article: Kill extra brand names to make your open source project more powerful by Chris Grams. 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. I was at a meet-up with lots of Java developers, and inevitably the conversation went to the topic of preferred Java IDE. I thought I’d heard all the arguments for why developers choose IntelliJ IDEA over Eclipse IDE, but this was a new one.
