aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emily Jiang <emijia...@googlemail.com>
Subject Re: Aries releases - oh, the misery
Date Mon, 05 Mar 2012 10:58:31 GMT
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 <david_jencks@yahoo.com>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/%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
>
>


-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

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