Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Best practice how to deal with different target platforms

Not sure if you missed it but the point he made was to not show an error. 

I agree with you that it is not sustainable
To maintain backwards compatibility with too old eclipse but some usecases do require it. 

So catching it via optional is the best compromise so far b


On 13 Feb 2016, at 09:48, Mickael Istria <mistria@xxxxxxxxxx> wrote:

On 02/12/2016 02:24 PM, Christian Pontesegger wrote:
I am wondering how other projects handle different target platforms for their projects. If you are not part of the release train, users might install your plugins into a wide range of eclipse installations ranging from 3.x versions up to the newest neon builds. While it is easy to set a minimum target platform, how do you deal with optional features that only exist in newer versions of eclipse.
I would love to hear how other projects handle these problems.
I believe at some point, users must understand that if they want better things, they'll have to update their software. Most contributors cannot spend enough energy/time in supporting multiple older versions of the IDE, and innovating at the same time.
Imagine someone going to ask Microsoft to have Office 2015 supported on Windows 98, do you think Microsoft would just say yet? It's definitely not the direction of innovation.

So IMO, the best strategy for the community as a whole (both contributors and users) is to really support the best target version, for example Mars, and only this one, If you only use features or APIs that were in previous versions, then having more open dependency range working (usual semantic versioning works well for that) and testing against older versions is a nice to have, but if you use a new feature API, then telling users who want this feature that they also have to update their IDE makes sense. Those who want to stick with older IDE can stick with older version of your plugins.

I would discourage strongly any mechanism that would show ClassNotFoundException to users. The whole design of versioning in OSGi was made to prevent from this error; using alternative strategies to reintroduce it is a regression. Users who face an exception just believe that the software they're using sucks, and do not necessarily imagine that they just have to update their IDE.
However, if this is a direction you really want to take, then you can imagine catching such exceptions when you can anticipate them and show a better "Please update your IDE to enable this feature" instead of an error.
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top