Bugzilla – Full Text Bug Listing
| Summary: | Manifest editor > Dependencies: Should add proper lower and upper version bound for required plug-in | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Markus Keller <markus.kell.r> |
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | ankur_sharma, caniszczyk, curtis.windatt.public, daniel_megert, darin.eclipse, hudsonr, jeffmcaffer, tjwatson |
| Version: | 3.6 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 330926 | ||
We had a bug on this before, can't find it. The problem with adding the upper bound is that it makes assumptions that people follow our API guidelines. This upsets some people. I think we could have a preference maybe for this. What does OSGi recommend? > What does OSGi recommend?
Version ranges encode the assumptions about compatibility. This specification
does not define any compatibility policy; the policy decision is left to
the importer that specifies a version range. A version range embeds such a
policy.
However, the most common version compatibility policies are:
• major – An incompatible update
• minor – A backward compatible update
• micro – A change that does not affect the interface: for example, a bug fix
==> I think the default in PDE should be the "most common policy". Users can always tweak ranges, and the most common default would upset the least amount of people.
Tom, can you comment on what the OSGi community expects here? (In reply to comment #4) > Tom, can you comment on what the OSGi community expects here? It is along the lines of what Markus outlines in comment 3. Ideally I would want that to be the default in PDE when a version range is specified. So if x.y.z is requested then the following is used as the range: [x.y.z, x+1.0.0) But there are concerns with changing the default here which Chris alludes to in comment 1. The problem is that bundle dependencies are very coarse grained. You add one breaking change in on package of your bundle and you must up your major version of the bundle. This will break every requirer even if a majority of them would work fine. But the flip side is that you also will break anyone that IS using the API which had a breaking change. I think the default should be the best practice which is to put an upper bound on the major version of the bundle/package. Bundle developers can always change the range if they do not like it. Seems like a reasonable request. If you right click the dependency, PDE has a special properties dialog that helps you match the proper version ranges. I'm still hesitant in making this the default. There have been a few bugs since I made the change to add the lower bound in 3.4 I guess our strategy can be to try to push this best practice onto people, if people complain, we can think about adding a preference to how version numbers are treated by PDE. *** Bug 330364 has been marked as a duplicate of this bug. *** My opinion has not changed on this issue. PDE should default to the best practice and have an option to override the best practice behavior for folks not following proper versioning rules (to their own demise). At the very least PDE should warn folks that are using unbounded ranges. Count my vote as showing best practices and driving people to have an upper bound There is definitely interest and value here, but I don't think Ankur or I have time to work on this. Certainly not for M4. I feel this doesn't deserves a preference. But I really like the idea. Curtis is right, don't see myself being able to pick it in near future. From Bug #330926 "When I add a new dependency, I get something like: com.company.foo;bundle-version="1.2.0" Which eventually becomes incorrect when 1.3.0 is actually being used for development and nobody updates the min-version. Or, it becomes annoying when the bundle is updated to 2.0.0, causing a false negative when compiling against the newer version of the dependency. Please provide a preference setting so that only the following is added when using the "Add..." action in the "Required Plug-ins" section of the manifest editor and related UI pieces (like quick-fix, etc.): com.company.foo" *** Bug 330926 has been marked as a duplicate of this bug. *** (In reply to comment #14) > com.company.foo;bundle-version="1.2.0" > > Which eventually becomes incorrect when 1.3.0 is actually being used for > development and nobody updates the min-version. For this, I'd prefer a warning from the manifest compiler (minimum required version doesn't match workspace version). See also bug 213020 and bug 255771. I'm leaving the 3.7 milestone for now, however, I don't think any of the committers will have time to work on a fix for this. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |
I20090901-0800 Plug-in manifest editor > Dependencies tab: The Add.. button should add the upper version bound for required plug-ins, e.g. org.eclipse.jdt.junit;bundle-version="[3.5.0,4.0.0)" instead of the open-ended org.eclipse.jdt.junit;bundle-version="3.5.0"