Following up to myself, I have option B ready to commit. I think the
changes to the transaction wrappers pom are most semantically correct
in terms of expressing the correct dependence on the util bundle, but
it's not at all robust. I had to special case how we handle package
imports from the util bundle (yuck), and hardcode a bundle version in
the transaction itests instead of relying on the maven-depends-plugin
(yuck yuck yuck).
I'm wavering between pragmatically committing and trying to rewrite
all the poms to try and avoid the ugliness, which I fear may be
somewhere between over-ambitious and hopeless.
Holly
On 4 Mar 2012, at 16:22, Holly Cummins
<[email protected]> wrote:
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 (http://mail-archives.apache.org/mod_mbox/aries-dev/201112.mbox/%[email protected]%3E
), 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.
Holly
* Or rather, we won't have independently releasable bundles
