Community
Participate
Working Groups
When using Import-Package PDE should warn/error the user when they specify a version with an open range: Import-Package: org.osgi.service.cm; version="1.0" This range specifies a range of 1.0 upto infinity. The recommended range should allow only up to the next breaking version by default: Import-Package: org.osgi.service.cm; version="[1.0, 2.0)" The problem now is PDE defaults to open ranges which is not a correct best practice. Clients, but default should not be expected to handle a breaking API change.
The same is true for Require-Bundle. I don't we should create open ranges by default when adding Require-Bundle dependencies.
I'll point out that major version segment in 3rd party bundles don't necessarily follow the same convention. In the SDK case, com.ibm.icu (both package imports and require bundle) have to be an open range, as their shift from 3.x to 4.x meant nothing w.r.t API compatibility and in the release train, the best practice for ICU is to only specify the lower bound (in most cases, 3.6 or 3.8). As long as it's only a warning (as opposed to error) it won't hurt anybody. PW
My main motivation is to change the default to not leave this as an open range. The problem with ICU is we have no idea when they plan to break the API based on their package versions. As a client this is very dissatisfying way of evolving API!
This is an ongoing debate. It feels like we should have the default be a closed range, however there are clients that do not follow the convention. As Chris suggested on bug 288396, we could have a preference, but then what should the preference default be. *** This bug has been marked as a duplicate of bug 288396 ***
