| Re: [equinox-dev] .qualifier for export package? |
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: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.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?
Note that all of these are independent of the use of .qualifier. Putting version numbers on package exports is just good hygiene.
Jeff