Thanks for your comments. I agree that option 1 is the technically best option. Unfortunately, it is very likely that at some point in the future, we will be forced into extending an API in an old version/branch anyway.
You write that if it is necessary, we should add it in the main branch first and then backport to maintenance branch(es) afterwards. Is there a best practice for how to handle the version numbering of exports and imports (safely) for such a backport? Or any tools available that can help? I worry that if we have to manually handle the fact that a build of a bundle is compatible or incompatible to other bundles manually, we risk errors resulting in method-not-found exceptions etc. Regards, Henning On Fri, Jan 25, 2013 at 4:16 PM, BJ Hargrave <[email protected]> wrote: > Option 1 is your best choice. API packages need careful, long term > architecture. They are the contract of your bundle. Adding such fixes in a > maint branch is dangerous as the package diverges over your branches. If > this is necessary, you need to fix first in the main branch and, when > happy, consider backporting to the maint branch(es). You need a linear > history of the package evolution. > > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/>* > **[email protected]* <[email protected]> > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > > From: Henning Andersen <[email protected]> > To: [email protected], > Date: 2013/01/25 10:02 > Subject: [osgi-dev] Fwd: Branching, versioning and API changes > Sent by: [email protected] > ------------------------------ > > > > Hi OSGi developers, > > we have been using OSGi for 3 years now, however without semantic > versioning. We now want to take our versioning strategy to the next level > by introducing semantic versioning and allowing individual release cycles > for different components in our system. > > One of the issues we are struggling with is how to handle branches and > versioning, especially in relation to API changes. > > Consider a package p with a single class C, with a single method m: > > package p; > > public class C { > public void m(); > } > > Now say, we released a bundle B in version 1.0, with this package in > version 1.0. To allow us to bug fix, the bundle B is branched into a 1.0 > branch too in our source code repository. > > Another bundle X has Import-Package: p; version="[1.0;2)" as per semantic > versioning and is released as version 1.0. > > Development of class C continues and a new method is added: > > public class C { > public void m(); > public void n(); > } > > This is released in a new version of B, bundle-version 1.1, package > version 1.1. > > Now a customer has X 1.0 and B 1.0. They request a new feature to X, but > reject to upgrade B. The feature in X requires an API extension to the > class C. So we add this in the 1.0 branch: > > public class C { > public void m(); > public void o(); > } > > If we were to follow semantic versioning, we should release this as B > version 1.1, p version 1.1. However, these numbers are already occupied. > > So we have to break the principle and release them as B version 1.0.1 and > p version 1.0.1. > > The developer of X now needs to import the package p in the right version. > However, using: Import-Package: p; version="[1.0.1;2)" is not entirely > right, since his code is not compatible with the 1.1 version. > > So far we have 5 solutions: > > 1. Do not allow it. Only allow extending the API in a new minor version > following the latest released version. > 2. Add an attribute to the export 'Export-Package: a; version=1.0.1; p.C.o > = true' and do the same on 'Import-Package: a; version="[1.0.1,2)"; p.C.o = > true'. Requires that we identify the dependency to method level. > 3. Fix the version of a in X: 'Import-Package: a; version="[1.0.1,1.1)"'. > This however has the implication that X need upgrade when we upgrade B. > 4. Build two bundles out of X, one with 'Import-Package: a; > version="[1.0.1,1.1)"' and one with 'Import-Package: a; > version="[1.1.1,2)"' (assuming the method was also added in 1.1.1). > 5. Branch X into two versions (much like 3), with different import versions > > We think some of these could work, but do wonder if others have run into > the same issues or similar branching/versioning issues and how they solved > it? Any input is highly appreciated. > > Thanks, > > Henning > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
