Hi > Am 08.12.2015 um 00:29 schrieb Francesco Mari <[email protected]>: > > 2015-12-07 21:02 GMT+01:00 David Bosschaert <[email protected]>: > > ... > The more frequent case is a change in the development branch (1.5) that has > to be backported to the maintenance branches (1.4, 1.2, 1.0). If the change > breaks the API of the affected packages, it could be troublesome - see > below. > > >> >> 1 and 2 above should be pretty simple and 3 should pretty much never >> happen anyway... >> >> Two additional notes. While we're talking about 'Oak 1.4' I assume >> that is the version of the bundle. I assume each package in that >> bundle evolves independently which means that they could have versions >> other than 1.4 (e.g. org.apache.foo = 1.1.2 and org.apache.bar = 1.3 >> etc). >> > > Packages evolve independently, but they do in potentially divergent > branches. This is the kind of timeline that we usually face: > > - Oak 1.4 has a package org.foo.bar 1.0 > - Some changes happen on the development branch 1.5 > - Oak 1.5 now has a package org.foo.bar 1.1 > - A change X happen in the development branch 1.5 > - Oak 1.5 now has a package org.foo.bar 1.2 > - The change X has to be backported to the maintenance branch 1.4 > - Oak 1.4 now should have a package org.foo.bar 1.1 > > Assuming that the versions were incremented following the semantic > versioning rules, we now have two packages - both called org.foo.bar and > both having version 1.1 - that live on two different branches and contain > different code. > > The only obvious solution that comes to my mind is to bump the major > version of every package right after the development branch 1.5 is started, > but I don't like this approach very much because it would break > compatibility with existing clients for no obvious reason.
This scenario is the exact problem you are facing while branching and evolving the branches in parallel to trunk. The only end-developer friendly solution is to byte the bullet and do it really properly and make sure you evolve exported packages (being your API) in a truly diligent matter: Consider a package name and its export version as the package’s identity and always make sure this identity (label) refers to the identical exported API. It’s a pain with unduly large exported packages, but its the only way you can serve your community. Regards Felix
