I don't think we can even contemplate this without full tooling 
automation. As Tom says, we struggle to keep our bundle version numbers 
correct as it is.  We can maintain package versions manually up to a 
point, such as base framework packages and service packages, but any wider 
scope would become unmanageable. For most of the wider Eclipse team that 
rarely/never uses import package, there is no immediate need to version at 
the package level.




Thomas Watson <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
01/11/2008 03:45 PM
Please respond to
Equinox development mailing list <[email protected]>


To
Equinox development mailing list <[email protected]>
cc

Subject
Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package  as 
API






Without tooling this will be difficult. If we wanted to use the big hammer 
approach the we would have the API tooling (or plain old PDE) mark exports 
without versions as a warning/error by default or update each project 
settings in eclipse to make it an error. Now the question is what version 
would all the well established packages use? Most eclipse packages do not 
specify a version which means they have been using the default version of 
0.0.0. If a package is being versioned for the first time what should its 
version be?

- Start off using 1.0.0
- Use the Bundle-Version

I favor using the Bundle-Version for well established packages because if 
we decide to add versions to the maintenance streams then we have room to 
downgrade the versions as appropriate. Completely new packages in a 
release should start off with version 1.0.

I have been trying to version the exports of org.eclipse.osgi for the past 
few releases. It is hard to keep track of without tooling. Just look at 
how many times we forget to increment the bundle versions in Eclipse and 
that is just one version number per bundle to maintain. Now we will have 
to maintain each package version individually which is a much bigger task. 
Hopefully more advanced API tooling could detect that the API package has 
changed since last release and needs to be incremented. Does the new API 
tooling currently do something like this for Bundle-Version? 

Tom



Jeff McAffer ---01/11/2008 02:17:11 PM---Tom raises a good point that we 
keep letting slide. Are we going to ensure that all export package 
statements have version num


From:

Jeff McAffer <[EMAIL PROTECTED]>

To:

[email protected]

Date:

01/11/2008 02:17 PM

Subject:

[equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API




Tom raises a good point that we keep letting slide. Are we going to ensure 
that all export package statements have version numbers for 3.4? If we 
have API tooling for this then it would likely be reasonable to start 
doing. Even without tooling today, we could introduce version numbers 
based on the bundle version number for this release and then evolve from 
there (with tooling that will come in the future). 

Jeff 

----- Forwarded by Jeff McAffer/Ottawa/IBM on 01/11/2008 01:22 PM ----- 
[EMAIL PROTECTED] 
01/11/2008 10:50 AM 


To
Jeff McAffer/Ottawa/[EMAIL PROTECTED] 
cc

Subject
[Bug 214801] [api tools] consider Export-Package as API








https://bugs.eclipse.org/bugs/show_bug.cgi?id=214801 
Product/Component: PDE / Incubators




--- Comment #2 from Thomas Watson <[EMAIL PROTECTED]>  2008-01-11 
10:50:13 -0400 ---
I agree with the concept.  All exported packages which are not marked
x-internal:=true should be versioned.  Without this it makes using
Import-Package very limiting because you cannot specify what version of 
the
package you require.  Packages marked as x-friends are questionable, but I 
can
see friend bundles depending on a particular friend package version.


-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the 
bug._______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]
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>>

<<image/gif>>

<<image/gif>>

<<image/gif>>

_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to