views:

44

answers:

1

Assuming that extending a class from an Eclipse plugin:

public abstract PluginClass {

     /** @since 1.0 */
     public void doSomething() { };

     /** @since 1.1 */
     public void doSomethingElse() { };
}

Is it safe to override doSomethingElse if I still want to support the 1.0 version of the plugin?

+1  A: 

If doSomethingElse() is never called by any of the since 1.0 methods... that may be ok.

But a good way to manage those kind of evolutions is to have a strict bundle version numbers policy.
For that, I would recommend the "PDE/API Tools/User Guide"

API tooling provides a builder that reports API usage and binary compatibility errors in the workspace.
You must configure bundles/projects that you want API tooling to report errors on and you must define an API baseline to compare against workspace projects (to report compatibility errors, missing @since tags, incorrect version numbers, etc.).

An API baseline defines the state you want to compare your development workspace bundles against for the purposes of binary compatibility, bundle version numbers, and @since tags.

So in your case, if you are developing bundles for your plugin1.1, you will use your plugin 1.0 as your baseline.

VonC
Note: see also this nice recent article on API tooling: http://eclipsepde.wordpress.com/2009/06/23/configuring-api-tooling-for-existing-projects/
VonC