aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <holly.k.cumm...@googlemail.com>
Subject Re: Aries releases - oh, the misery
Date Mon, 05 Mar 2012 11:43:57 GMT
Personally, I vote we do both, profiles and moving to 1.0 releases. :)  
It really did look like you had a terrible time with the util bundle,  
Emily, judging from the size of the changeset. We're making work for  
ourselves by using non-semantic versioning, and I'm not sure we're  
getting benefit anymore.

Phrasing the question differently, then, are there reasons *not* to  
move to a 1.0 numbering scheme now?

Holly

On 5 Mar 2012, at 10:58, Emily Jiang <emijiang6@googlemail.com> wrote:

> 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
View raw message