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
