FYI - plans for package version support in API tooling have been reduced.
Currently, there is nothing on the draft plan due to resources available
to do the work, and the fact that SDK plug-in developers generally use
components at the plug-in granularity vs. package granularity. I'm not
sure there is a compelling story to have SDK bundles change to using
package imports.
Resource point taken I feel compelled to point out that PDE is
plugin/bundle tooling not SDK tooling. The success of Equinox and OSGi
is largely predicated on developers being able to develop bundles
whether they be for the SDK, RCP or server side applications. As Tom
pointed out previously, using import-package without version numbers is
questionable. So fundamentally, the various runtime/RCP related bundles
in Eclipse should be putting version numbers on their exports. If they
are going to do that reliably, there needs to be tooling.
To start, I would like to see a better specification developed/agreed upon
before tooling is introduced. Currently, the description of package
versioning is minimal - leaving questions to the developers and tool
implementors:
http://wiki.eclipse.org/Version_Numbering#How_to_version_packages
Here are some obvious questions:
* How are @since tags formatted to indicate that the version number
corresponds to packages vs. bundles?
* How are initial package versions derived for existing bundles?
Keep it simple. initial package version == current bundle version
number. @since is package related. Package version numbers increment
with the same semantics as bundle version numbers.
Note that all of these are independent of the use of .qualifier.
Putting version numbers on package exports is just good hygiene.
Jeff
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev