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, 26 Mar 2012 08:30:14 GMT
Hi David,

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 know what you mean about the lack of a permanent record in svn of what
you built with being slightly uncomfortable. On the other hand, I think
we'd always want to use some kind of 'LATEST' shorthand when depending on
snapshots, wouldn't we? (Either within a profile or as a temporary change
to the poms.) Actually writing down the snapshot versions in lots of places
seems like a maintenance burden in the best case, and in the worst case we
could get it wrong and *think* we were building against the latest version
when in fact we were building half-against the latest version, and half
against the released version. The versions plugin would make this
maintenance slightly easier but still allow for inconsistent states if we
forget to run it.

>
> 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.
>

If developers do the sequence

[make pom changes]
[build against minimum dependencies, the default]
[build against latest snapshots, using:] mvn clean
versions:use-latest-versions install
[revert to their local updated poms] mvn versions:revert
[commit]

things will work well. Problems will occur if they forget to do the revert
or make changes after doing versions:use-latest-versions. Forgetting to
revert would mean they'd obliterate all our carefully maintained
information about minumum dependency versions, and making changes after
running the version plugins means their changes would be lost when they
reverted. The reversion just uses a local backup copy, rather than pulling
things down from svn, so changes make before running the versions plugin
would be preserved.

In contrast, with the profiles, there's much less risk of a garbled commit,
but also more maintenance work to ensure we're building against what we
think we're building with. I guess it partly depends how often we expect
developers to build in both modes. There's no risk in getting Jenkins to
build with the snapshots and minimal versions, so the issue is only for
developer sandbox builds. If developers will build in both modes a lot, we
want the lower risk variant, whereas if they occasionally do it, we perhaps
want to take advantage of the existing versions plugin infrastructure for
reduced maintenance effort.

Holly


> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message