If you change API during dev cycle, that is the proper time to also change 
the major or minor version.  That is the whole point. I would assume that 
API tooling will complain until you do so. Just changing the qualifier is 
insufficient to capture an API change. Also, I think that last thing we 
want to see are bundles using qualifiers in import package statements! So 
if you use qualifier to denote API change during dev, then other bundles 
will need to import using qualifiers to ensure they wire to the desire API 
if they use it. UGLY!

Qualifiers are useful to capture implementation changes. But API is a 
specified thing that changes deliberately and (hopefully) slowly and its 
version is not subject to implementation. 
-- 

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:
Jeff McAffer <[EMAIL PROTECTED]>
To:
Equinox development mailing list <equinox-dev@eclipse.org>
Date:
2008/09/03 06:16 AM
Subject:
Re: [equinox-dev] .qualifier for export package?



I understand your hestiation and actually agree with you from the 
"released code" point of view.  However, we spend a lot of time dealing 
with code and API that is in development.  If we are to have any hope of 
provisioning and managing that, we need to know the difference between the 
various iterations of the packages.  For example, when someone adds an API 
during the dev cycle and you want use it, you need to import the right 
version of the package to ensure you get it.  Changing the first three 
segments version number of the package for every change done in the dev 
cycle feels too disruptive.

To a certain extent this could be handled in the provisioning system but 
that would force the situation of bundles in a particular context (e.g., a 
build "lineup").  That is, bundles would no longer be 
completely/accurately self-describing.

Jeff

BJ Hargrave wrote: 

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



_______________________________________________
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