re the idea of profiles for dependencies at released versions and
snapshots (ARIES-798) -- I tried this out, it is very easy to set
up, but
IIRC I got no feedback one way or another. I still think it's a
good idea
and am happy to set it up on the rest of the aries subprojects if
people
like it.
david jencks
On Mar 4, 2012, at 8:22 AM, Holly Cummins 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
