Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API

You need to, as part of the release process, use tooling, like japitools, to examine each package for changes, including non-backwards compatible changes. Then, at the end of the release, the package and bundle version numbers can be properly increased. We do this in the OSGi release process.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
Office: +1 386 848 1781 Mobile: +1 386 848 3788


 ----- Original Message -----
  From: Thomas Watson
  Sent: 01/11/2008 01:45 PM
  To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
  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



Inactive hide details for Jeff McAffer ---01/11/2008 02:17:11 PM---Tom raises a good point that we keep letting slide. Are we gJeff 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 <Jeff_McAffer@xxxxxxxxxx>

To:

equinox-dev@xxxxxxxxxxx

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 -----
bugzilla-daemon@xxxxxxxxxxx

01/11/2008 10:50 AM

To
Jeff McAffer/Ottawa/IBM@IBMCA
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 <tjwatson@xxxxxxxxxx>  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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

GIF image

GIF image

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

Back to the top