Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Notice your files have changed?

I made a "bulk change" to all our WST and JST 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)"
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
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.

Back to the top