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.
I fail to see how this would work with branches. For Francesco's example
this would mean that we'd need to backport everything into the branch
effectively aligning it with trunk and thus obviating its purpose.
Michael
