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
