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/%[email protected]%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 <[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 >> >>
