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 [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
