Before recommending every package uses a qualifier I have the following concerns:
1) In Eclipse we have loads of packages. We better make sure all identical
qualifier Strings are shared (interned etc.) for performance reasons.
Today when loading from a cached state we share identical Version objects.
Because package versions are managed independently we will end up with lots
of different versions that have the same qualifier exported by a bundle.
We also will limit the ability to share Version objects across bundles
because each will use a different qualifier (unless we happen to use the
same CVS tag).
2) The qualifier will change even in cases where no code was touched in the
package. I'm not sure this is a valid concern. The code got recompiled so
perhaps changing the version qualifier is warranted. But we need to think
about the consequences. For example, I can see API tooling start to
complain that the micro version of a package should be increased to
indicate a bug "fix" when comparing the package versions with a base line.
It will notice that the qualifier changed from a previous release but the
micro version was not increased.
3) What about versions of packages which we do not maintain the API for at
Eclipse. Things like org.osgi.* and orbit bundles. Shouldn't we use the
version the producers of the API have defined? Adding a qualifier here
does not seem right, especially if a qualifier is already defined by the
producers.
On the surface this sounds like a fine idea, and I am not completely
against it. But I would like to take the first step of versioning the
Eclipse API packages first to see what all the issues are with independent
package versioning. I'm sure we will run into other hurdles along the way.
For example, how does a developer maintain the version of a split package
across all the bundles the package is split?
Tom
From: "Chris Aniszczyk" <[EMAIL PROTECTED]>
To: "Equinox development mailing list" <equinox-dev@eclipse.org>
Date: 08/31/2008 02:46 PM
Subject: Re: [equinox-dev] .qualifier for export package?
On Sun, Aug 31, 2008 at 5:53 AM, Jeff McAffer <[EMAIL PROTECTED]> wrote:
As version numbers on packages become more prevalent does it start making
sense to use .qualifier on them in addition to bundle version numbers?
The logic here is the same as for bundles. we rev the version number of
the bundle to match the most extreme change for that release. in between
if hte provisioning system is going to do its job, it needs to have
different version numbers. Teh .qualifier allows for the
auto-qualification of bundle version numbers. The same is true for folks
using import/export package.
+1
In PDE, I plan on releasing some builder logic to flag exported packages
without versions with a warning in M2. API Tooling also has items in plan
that deal with package versioning, but that will be post M2
Thoughts for how/if this should be introduced?
I say before M2, we formulate a plan across the Eclipse proper projects to
deal with versions on package exports. We can than look at pushing that
plan to other Eclipse.org projects as a best practice once we get the hang
of it.
--
Cheers,
~ Chris Aniszczyk_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
