|RE: [eclipse.org-architecture-council] The Art of Project Release Naming|
I assume this implies that we’re not going to mix the marketing release name (e.g., “Helios”) with the engineering version number, and keep the version numbers unconstrained. It may be the best compromise, but I have a concern that’s similar to the one John states below. A lot of people still consider the version of the Galileo coordinated release to be 3.5. It was tweeted as #eclipse35. When I get asked about Mylyn version by those who aren’t Eclipse insiders I’ll find myself saying “Mylyn version that shipped with Eclipse 3.5”. The ECF download page states: “ECF 3.0 Install via P2 Repository -- for use with Eclipse 3.5”. I always make an effort to use “Galileo” and proper version numbers, but then end up saying things like:
“Make sure that you’re on Eclipse 3.5, with Mylyn 3.2, WTP 3.1 and ECF 3.0.”
Which tends to result in a confused stare as someone tries to pick their way through our 3.x version soup.
For users that just want the latest thing, we’re in a pretty confusing state due to the various version number, so the naturally fall back to the version of the Platform. The fact that so many of the numbers are 3.x just adds to the confusion. (That seems be a point of convergence for API stabilization.)
Taking the user’s point of view, this has made me secretly wish that we had a coordinated opt-in version number for projects, pegged to the Eclipse Project’s. Projects that are big enough to effectively market their version number, such as BIRT and WTP, could opt out. For integrators, bundle/API version numbers would evolve as they do now. In other words, just as platform versions its components separately from the coordinated 3.5 version number, projects would still use their own internal versioning, but could advertise their release version as part of Eclipse 4, then Eclispe 5, and avoid the scenario where a few years down the road we’re trying to communicate a dozen different 3.x and 4.x versions.
Back to the top