aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Aries releases - oh, the misery
Date Sun, 25 Mar 2012 21:41:52 GMT
Hi Holly

I sure didn't think of that :-)

I don't like it because there's no record in svn of what you actually built with.  I do envisage
using the versions plugin to update the snapshots profile, although I don't recall checking
to see if it worked "inside" a profile.

I also think, as I think you hinted, that it's going to be really confusing on a developers
machine to remember what state the pom is in.  If you want to make a change to a pom and try
both profiles before committing I think you'll have a hard time reverting just the version
changes and keeping the ones you mean.

thanks
david jencks

On Mar 25, 2012, at 1:55 PM, Holly Cummins wrote:

> Hi,
> 
> I've been thinking more about the profiles for released versions and
> snapshots. David J. has suggested maintaining profiles for released
> versions and snapshots so we can accommodate both the requirement for
> independently releasable modules, and the requirement that a current slice
> across all modules had better work (
> http://mail-archives.apache.org/mod_mbox/aries-dev/201112.mbox/%3C6A8EEF8C-F116-40B4-8256-8276EA7DADA0@yahoo.com%3E).
> David J., what was the reason for using a profile rather than the versions
> plugin? I'm thinking of using something like the following to build with
> snapshot versions:
> 
> mvn clean versions:use-latest-versions install
> 
> 
> It seems like it would be much simpler than profiles, because we wouldn't
> have to maintain any profiles.
> 
> I guess one downside is that such an invocation would work great in a
> Jenkins environment, where there was no plan to commit things back, but it
> would be lousy in a developers' sandbox, where the changes made by the
> versions plugin get mixed in with other changes, and we'd have to be very
> careful not to commit them by doing versions:revert. Other than that
> objection, were there other downsides?
> 
> Holly
> 
> 
> 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
>> 
>> 


Mime
View raw message