aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Aries releases - oh, the misery
Date Mon, 05 Mar 2012 00:30:19 GMT
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/%3C657FB750-83C5-45F9-83B1-93137594B3E9@yahoo.com%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


Mime
View raw message