aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <>
Subject Aries releases - oh, the misery
Date Sun, 04 Mar 2012 16:22:45 GMT
Hi all,

A while ago we were discussing the long-anticipated JPA release, and I
mentioned that I'd try and do a bug-fix release of the transaction-wrappers
bundle to try and get my feet wet with the release process.

Well, I've had a try, and I'm now feeling rather sodden, if not actually
drowned. I hate to re-open the subject of releases, since it's a bit of a
dead horse, but I think we're going to have continuing release issues*
until we do two things:

1. Move to a 1.0 release. Until we do this, we can't have proper semantic
versioning, because we've cut off part of the version range and therefore
overloaded other parts of the range. It's ambiguous whether a change from
0.4 to 0.5 is a breaking change or not. We used to version our internal
package imports as [0.x,1.0), but we hit problems on our last batch of
releases where bundles accepted incompatible versions of their
dependencies. Now we tend to lock everything down to the next minor
increment. This means that when a bundle is released, released versions of
bundles which depended on it no longer resolve with the new packages, and
must themselves be re-released.
2. Be consistent in whether we depend on released versions or the latest
snapshots in our poms. Otherwise we aggravate the problem caused by
incomplete semantic versioning and end up having to release an even bigger
web of bundles per release. We discussed this in December (
), and David Jencks raised ARIES-798 to cover creating profiles to allow us
to switch between released and snapshot versions.It looks to me like David
started but then decided the problem was just too hard - is that right,
David? At the moment we have a mix of snapshot and released dependencies
which makes it pretty hard to work out where we actually need a snapshot,
and where we're just using the latest and greatest to ensure test coverage

As a case study, let me explain what I've hit trying to release
transaction-wrappers, a very boring bundle with only two dependencies,
aries.util and aries.transaction.manager. Both are snapshot dependencies,
but I know by code inspection the transaction wrappers bundle will work
fine with the released versions. However, if I move to the released
versions, things rapidly unravel.

In particular, moving to the released util bundle leads to test failures in
the transaction itests. What's happening is that if I use
org.apache.aries.util-0.4 as my pom dependency, the itests use the 0.4 util
bundle for testing. All of the other transactions bundles have a dependency
on 0.5-SNAPSHOT, so none of them will resolve. As far as I can see, I have
three options.

A. Identify by code inspection that none of the transaction bundles
actually need util-0.5, and revert to using released dependencies for the
whole transaction component. However, see point 2 above - since we declare
a dependency on the snapshot, it's pretty tedious to work out whether this
is a 'real' dependency or one which was done for ease of testing.
Furthermore, the changes to snapshot levels were introduced in ARIES-820,
as part of a general move to snapshot dependencies on util. So I can back
out the parts of ARIES-820 which relate to the transactions bundles. Sadly,
this just deepens the hole. I then have to do lots of tinkering to increase
the upper range of the util packages imported by the transactions bundles,
or tests in other components (which use util-0.5) will fail. Even to get a
set of bundles for the transactions itests which can resolve against means
changing dependencies in areas like blueprint-core.

B. Make the minimal change. After trying to do option A, this is pretty
appealing. Since I know transaction-wrappers works against util-0.4, all I
need to do is depend on util-0.4, but test with util-0.5 in the itests. The
downside is that this leaves a bit of a testing hole, but the combinatorics
of testing against every version we declare we support are intimidating.
However, it also means hard-coding versions, having bundle-specific
policies for what package versions of org.apache.aries.util we import, and
hacking around with pax-exam to persuade it not to test with the minimum
versions of the declared dependencies. It feels pretty icky, and it's a bit
of a band-aid.

C. Realise that any release involving bundles with a dependency on util-0.5
is going to have the exact same issues I'm seeing. Since pretty much every
component depends on util-0.5, stop trying to release transaction-wrappers
and just release util-0.5 first. This means everything can move back to
depending on the released version of util-0.5, and future releases should
be easier - sort of. Once some released bundles depend on util-0.5, no
bundle which depended on util-0.4 will resolve, so we'll actually just need
to release the whole project and abandon release-by-bundle for the moment.

I think we're going to continue seeing problems like this as long as we
have to keep our package imports locked down to minor increments (because
of point 1), and as long as we have snapshot dependencies scattered all
over the place (point 2).

Have we got a roadmap for moving to a 1.0 release? I guess it's too big a
job to be practical on a short timescale, but it will save time and make
life easier for our consuming projects once we get there, so it might be
worth keeping our eye on that goal.


* Or rather, we won't have independently releasable bundles

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message