I prefer we move to release 1.0. In this way, we can start smenaticly versioning our packages/bundles by using the versioning tool. We have graduated and it is about time to declare the baseline of our Aries APIs.
I did have a horrible experience of moving the minor version of the util bundle in the trunk. I am in doubt of the benefit we achieved with releasing by module:(. Regards, Emily On Mon, Mar 5, 2012 at 12:30 AM, David Jencks <[email protected]>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 ( > > > 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 > > -- Thanks Emily ================= Emily Jiang [email protected]
