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
