Eclipse — Managing your upgrade path

Eclipse — Managing your upgrade path

What’s the latest version of Eclipse? Which version of Mylyn works well with Eclipse 3.6.2? How do you configure a toolchain for a project that was developed with Eclipse 3.5?

As an Eclipse committer I sometimes like to think the answer is simple: Use the latest milestone builds and the add-ons from the Indigo site. If that’s too bleeding edge then use Helios. While this simplistic advice is easy to follow, in many cases it’s not practical.  Many organizations have much stricter rules:

Development environments must be ‚reproducible‘.  This is not as simple as each developer should use the same setup. This goes as far as to say, when working on legacy software, developers must use the exact same setup they did when the code was first written (say 5  years ago).

To achieve this, many organizations create VMWare images of their development environments and then share those among team members.  Workspaces settings are then managed by Zipping-up and Sharing the workspace directory.  While this chicken-wire and duct tape solution may work, it’s very difficult to propagate changes to your team.

This is the problem that Yoxos addresses and today I pushed the latest Eclipse release (3.6.2) to our Yoxos servers. With the latest version of the Yoxos Launcher you can now choose your upgrade path.  If you are happy with (or require Eclipse 3.6.1) you can now stick to that release.

On the other hand, you can stick to Eclipse 3.6.x, upgrading to new service releases as they become available.

Setting the appropriate upgrade path on your Yoxos profile will ensure that all your team members are using identical development environments and your current configuration will remain reproducible.  Team members simply need to install the Yoxos launcher and double click the profile.  This will get you up and running faster with Eclipse.

Yoxos supports 5 Different upgrade paths:

  1. Sticky: Sticky means that you will never upgrade, and you will work with this toolchain forever.  This is important for enterprise customers if they have to re-create the exact toolchain (bugs and all) that was used in the past.
  2. Critical: Critical means that nothing is removed, and only critical fixes are applied.  An example of this would be the upgrade from 3.6.1 to 3.6.1a (if a re-spin was needed for example).  If you set this, you will not get 3.6.2.
  3. Service: Service will take any critical updates as well as automatically moving you to the next service release. For example, from 3.6.1 to 3.6.2. However, you will not get 3.7. Service updates may (highly unlikely) remove functionality. For example, if a plug-in specifies an exact dependency on 3.6.1, then this plugin will be removed in 3.6.2.
  4. Minor: Minor updates will include all critical and service updates, as well as moving you to the next Minor release. For example, you will move from 3.6.1 to 3.6.2 to 3.7.0 (when 3.7 is released).
  5. Major: Major updates will always keep you on the latest Yoxos slice. You will move from 3.6.1 to 3.6.2 to 3.7.. however, if there is a 4.0 slice, you will be moved here instead.  This is for those people who always want the latest!

With the latest Yoxos repository, we now have 1,677 Components (features) and over 10,000 Eclipse plug-ins.