[wtp-dev] Notice your manifest.mf files have changed?

[David M Williams <david_williams@xxxxxxxxxx>]

I made a "bulk change" to
all our WST and JST manifest.mf files, so that the bundles required in

Require-Bundle:  sections specify
a "range" of appropriate version numbers of the pre-reqs. 
For example, 
Require-Bundle:  org.eclipse.core.runtime;bundle-version="[3.2.0,3.3.0)"

or 
Require-Bundle:  org.eclipse.core.runtime;bundle-version="[3.2.0,4.0.0)"

The former form is known as "the
conservative" range .. the later 
as the optimistic range. I've used conservative
ranges throughout 
all of  our plugins, thinking this
is the best "default" value to use. 

See bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=143120
or recent post on cross-project mailing
list for more details. 

Here's the action required from component
leads: 

No action if your happy:
If you're happy with the defaults, after
reading the following, 
no action needed. 

Check my work: 
This mass change was partially tool
and partially "by hand", so 
be sure to check for any obvious errors
I may have made. 

Increase upper bound: 
If you have great confidence that your
plugin does not use 
non- API in the required bundle, you
can be more optimistic 
and use the larger number, if you'd
like. (Please open a 
new bug, for PMC review, at this late
point). 
For Eclipse pre-reqs, by using the conservative
value, we 
are pretty much (only) saying that we
will come out with a new 
release when there is a new release
of Eclipse. And, since 
that is the plan, there is not great
need to update. 
(And, remember, non-API includes extension
points, 
string constants of various types, etc.,
which, I don't believe, 
we yet have any scanning tools to check
for, in addition to the 
to "do not subclass", "do
not insatiate" sorts of rules). 

Third-party complicatoins: 
I think our use of some third-party
plugins may be the more 
troubling spot. If, for example, we
knew that Xerxes was coming 
out with a 2.9 version in a few months
.. and if we were sure we 
did not depend on any "internal"
API or behavior of Xerces 2.8, 
then we could in theory "spec"
xerces requirement of [2.8.0, 3.0.0) so 
xerces could be updated "in the
field" without us changing our 
plugins. So .. if anyone has any knowledge
of these third party
plans, those would be good ones to update,
if and only if we 
are sure we do not rely on the internals
of the current version,

Minor note on WSI: I noticed it actually
spec'd "runtime 2.1" for 
one of its Eclipse pre-reqs ... was
this intentional? Some need for 
backwards compatibility? If it was just
an oversight, no action 
needed (I changed to 3.2) but if you
need the lower number, you'll 
have to change. 

As we move forward, provide more API,
clean up our own 
dependancies, etc., this version range
will be more and more 
important as plugins are "mixed
and matched" for various 
products and adopter uses. 

Any questions are welcome.