aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <>
Subject Re: Aries releases - oh, the misery
Date Sun, 25 Mar 2012 20:55:41 GMT

I've been thinking more about the profiles for released versions and
snapshots. David J. has suggested maintaining profiles for released
versions and snapshots so we can accommodate both the requirement for
independently releasable modules, and the requirement that a current slice
across all modules had better work (
David J., what was the reason for using a profile rather than the versions
plugin? I'm thinking of using something like the following to build with
snapshot versions:

mvn clean versions:use-latest-versions install

It seems like it would be much simpler than profiles, because we wouldn't
have to maintain any profiles.

I guess one downside is that such an invocation would work great in a
Jenkins environment, where there was no plan to commit things back, but it
would be lousy in a developers' sandbox, where the changes made by the
versions plugin get mixed in with other changes, and we'd have to be very
careful not to commit them by doing versions:revert. Other than that
objection, were there other downsides?


On Mon, Mar 5, 2012 at 12:30 AM, David Jencks <>wrote:

> 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 (
> >
> > ), 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

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