I would be extremely cautious about using qualifier on package versions. I 
must say that I have never seen it done.

It seems an over specification. I think that having build tools to advise 
you to increment the micro is more than sufficient.
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]

office: +1 386 848 1781
mobile: +1 386 848 3788





From:
Thomas Watson/Austin/[EMAIL PROTECTED]
To:
Equinox development mailing list <equinox-dev@eclipse.org>
Date:
2008/09/02 10:45 AM
Subject:
Re: [equinox-dev] .qualifier for export package?



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



"Chris Aniszczyk" ---08/31/2008 02:46:34 PM---On Sun, Aug 31, 2008 at 5:53 
AM, Jeff McAffer < [EMAIL PROTECTED]


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

_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

<<image/gif>>

<<image/gif>>

<<image/gif>>

<<image/gif>>

<<image/gif>>

<<image/gif>>

<<image/gif>>

<<image/gif>>

<<image/gif>>

_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to