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, 04 Mar 2012 22:06:13 GMT
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.


On 4 Mar 2012, at 16:22, 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, 7-Bit, 0 bytes)
View raw message