Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330364

Summary:	Should warn on importing packages with no version or with open versions
Product:	[Eclipse Project] PDE	Reporter:	Thomas Watson <tjwatson>
Component:	UI	Assignee:	PDE-UI-Inbox <pde-ui-inbox>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	curtis.windatt.public, hargrave, jeffmcaffer, pwebster
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Thomas Watson

2010-11-16 10:12:12 EST

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.

Comment 1 Thomas Watson

2010-11-16 10:15:19 EST

The same is true for Require-Bundle.  I don't we should create open ranges by default when adding Require-Bundle dependencies.

Comment 2 Paul Webster

2010-11-16 10:28:16 EST

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

Comment 3 Thomas Watson

2010-11-16 10:37:49 EST

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!

Comment 4 Curtis Windatt

2010-11-17 12:19:58 EST

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 ***