Step 1) Separate your API interfaces into their own bundles, with their
own release cadence.
Step 2) Code solely against APIs, and against version ranges ( we use
[1.0.0,2.0.0) style.
Given things in OSGi land are service/interface orientated this works well.
We try to follow the semver style of version number, changing the major
(1.0.0->2.0.0) for backwards incompatible changes, and a minor
(1.0.0->1.1.0) for backward compatible, but forward-incompatible
changes. Any downstream bundle that requires the new API changes and
simply change their lower-bound in the range: [1.1.0,2.0.0)
On 19/06/12 1:19 PM, James Carman wrote:
We are an OSGi shop. Thus, we have a lot of "bundle" projects that
have their own independent release cycles. We have a hierarchy of
parent POMs and many utility libraries. When we change one of the
upper-level POMs (like the "base" for all of our OSGi bundles), it is
very time-consuming to point all of the downstream projects at the new
version. How do folks typically handle this? There has to be an
easier way. I found the versions plugin [1], but that can only get
you so far. You still have to cut each of the releases and re-point
everyone at them. Yuck!
[1] http://mojo.codehaus.org/versions-maven-plugin/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
