Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@aries.apache.org, dev@karaf.apache.org
Subject: Re: Plans for release of aries blueprint 0.4.1?
Date: Fri, 04 May 2012 15:47:29 -0400
Message-ID: <1432214.DliNu2Ruqg@dilbert.dankulp.com>
User-Agent: KMail/4.8.2 (Linux/3.2.2; KDE/4.8.2; x86_64; ; )
In-Reply-To: 
 <CAEQV+EGi+FdjbbBxwja7UqrX4Mu3mbd2bLynXDVSUBTtQz4nyg@mail.gmail.com>
References: <4F8614C5.1090000@lmco.com>
 <CAEQV+EF55tUqrEERwMfZV6BU3JDiBE43JAvvgKu7=TGjnHzeHQ@mail.gmail.com>
 <CAEQV+EGi+FdjbbBxwja7UqrX4Mu3mbd2bLynXDVSUBTtQz4nyg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"


(and  sending again from my apache id so the lists will accept it.  Sorry 
for the dup)


On Friday, May 04, 2012 08:44:45 PM Guillaume Nodet wrote:
> What would people think of changing the groupId of the 0.3 maintenance
> branch to something like org.apache.aries.m03 so that we don't have any
> clash between the 0.3.1 release coming from that branch ?

I chatted a bit with Guillaume on IRC.  I'd much prefer trying to move 
forward with patching the individual bundles that require patching and 
releasing them individually if at all possible.  

For blueprint, I think we can get away with:

1) create a branch to release a blueprint-core-0.3.2 from the appropriate 
part of the 0.3.1 tag which contains the fixes required.   Release that.

2) create a branch for the blueprint-0.3.2 for the bundle from the 0.3.1 
tag.  Build it using the 0.3.1 tagged versions of everything other than the 
new core.   

We MAY be able to grab the 0.3.2 versions for the annotation things as those 
changes are minor.   However, we cannot grab the 0.3.2 version of .cm as 
that requires bp 0.4.  (I really think the cm release is bogus due to this.  
How can 0.3.2 be a "patch" when it REQUIRES a minor update to a dep?)

Dan


> 
> On Fri, Apr 13, 2012 at 20:30, Guillaume Nodet <gnodet@gmail.com> wrote:
> > On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes <hughesj@apache.org> wrote:
> >> On 12 April 2012 17:10, Guillaume Nodet <gnodet@gmail.com> wrote:
> >> > Fwiw, I have a local fork of the 0.3.x aries maintenance branch which
> >> > we
> >> > could use as a basis for releasing our own version of the code if we
> >> 
> >> need.
> >> 
> >> > I think that would be beneficial for the Karaf 2.x branches where we
> >> 
> >> could
> >> 
> >> > get a bunch a bug fixes that we can't otherwise access.
> >> > 
> >> > I know Geronimo has already released forked Aries code, (I suppose
> >> 
> >> because
> >> 
> >> > of the exact same issue) so I don't think that's a real problem:
> >> http://repo1.maven.org/maven2/org/apache/geronimo/ext/aries/blueprint/o
> >> rg.apache.aries.blueprint/
> >> 
> >> I'm not sure where the source for that is, since they don't have svn
> >> elements in their pom. I'd *much* prefer to release Aries from the
> >> Aries project. Creating forks in Karaf and Geronimo won't help keep
> >> the Aries community together. After all, where does a user go to
> >> discuss that Geronimo release of Aries? The Geronimo list or the Aries
> >> list. As a fork it splits the community.
> > 
> > It does, and I don't think that's ideal.  However I don't see how to do
> > a
> > maintenance release of 0.3.x branch given some 0.3.1 bundles have
> > already
> > been released from trunk. The only solution I have in mind is to rename
> > the groupId.   If you have a better solution, I'd be happy to hear it.> 
> >> So I'm +1 for doing Aries maintenance releases, but -1 for doing them
> >> outside Aries.
> >> 
> >> > Thoughts ?
> >> > 
> >> > On Thu, Apr 12, 2012 at 17:18, Holly Cummins <
> >> 
> >> holly.k.cummins@googlemail.com
> >> 
> >> >> wrote:
> >> >> 
> >> >> Hi,
> >> >> 
> >> >> Unless it's based on a branch from an older blueprint level, I'm
> >> >> fairly
> >> >> sure that releasing blueprint 0.4.1 isn't much less work than
> >> >> releasing
> >> >> 1.0.0.
> >> >> 
> >> >> The reason is that the new blueprint code will only resolve against
> >> >> a
> >> 
> >> new
> >> 
> >> >> version of the util bundle. No existing bundles will resolve against
> >> 
> >> the
> >> 
> >> >> new util bundle, so any bundles with a util dependency will also
> >> >> need
> >> 
> >> to be
> >> 
> >> >> re-released.
> >> >> 
> >> >> This is pretty wretched, but such issues should go away once we're
> >> 
> >> using
> >> 
> >> >> version numbers above 1.
> >> >> 
> >> >> I'm going slightly slower with the 1.0.0 work than I could because
> >> >> I'm
> >> >> making sure that all the 1.0.0 bundles work together; at the moment
> >> >> I'm
> >> >> unpicking a problem with the application deployment tests and recent
> >> >> testsupport bundles, for example. This could be deferred until after
> >> 
> >> the
> >> 
> >> >> first 1.0.0 bundles roll off the assembly line, depending how
> >> >> urgently
> >> >> Karaf need a new release. I think it's neater to do things as I am,
> >> >> but
> >> >> pragmatism and neatness aren't always friends.
> >> >> 
> >> >> In either case, a new release hasn't been forgotten, and I am
> >> >> working
> >> 
> >> away
> >> 
> >> >> at it. :)
> >> >> 
> >> >> Holly
> >> >> 
> >> >> 
> >> >> On 11 Apr 2012, at 19:33, "Yonker, Jonathan"
> >> >> <jonathan.yonker@lmco.com
> >> >> 
> >> >> wrote:
> >> >>  Hello,
> >> >>  
> >> >>> From reading through the mailing list, it appears that I'm not the
> >> 
> >> only
> >> 
> >> >>> one with this question, but I still have to ask. Is there currently
> >> 
> >> any
> >> 
> >> >>> timeline for the 0.4.1 release? It appears that all issues in JIRA
> >> 
> >> were
> >> 
> >> >>> resolved quite a while ago, so it appears that the only problem are
> >> 
> >> the
> >> 
> >> >>> release problems that I've been reading about on the mailing list.
> >> >>> The
> >> >>> project that I'm working on runs on Karaf and we're eagerly
> >> >>> awaiting
> >> 
> >> some
> >> 
> >> >>> of the bugfixes from the 0.4.x branch, but Karaf is waiting for
> >> >>> 0.4.1
> >> >>> before they upgrade from 0.3.1 ( https://issues.apache.org/**
> >> >>> jira/browse/KARAF-988 <
> >> 
> >> https://issues.apache.org/jira/browse/KARAF-988>).
> >> 
> >> >>> Does anyone have a good guess on the feasibility of releasing 0.4.1
> >> 
> >> rather
> >> 
> >> >>> than just going right to 1.0?
> >> >>> 
> >> >>> Thanks for any updates you can provide!
> >> >>> 
> >> >>> Thanks,
> >> >>> Jon
> >> > 
> >> > --
> >> > ------------------------
> >> > Guillaume Nodet
> >> > ------------------------
> >> > Blog: http://gnodet.blogspot.com/
> >> > ------------------------
> >> > FuseSource, Integration everywhere
> >> > http://fusesource.com
> > 
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > FuseSource, Integration everywhere
> > http://fusesource.com
-- 
Daniel Kulp
dan@kulp.com
http://dankulp.com/blog