You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Guillaume Nodet <gn...@gmail.com> on 2012/04/12 18:10:41 UTC

Re: Plans for release of aries blueprint 0.4.1?

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/org.apache.aries.blueprint/

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" <jo...@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

Re: Plans for release of aries blueprint 0.4.1?

Posted by Freeman Fang <fr...@gmail.com>.
+1

Freeman
On 2012-4-13, at 上午12:10, Guillaume Nodet 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/org.apache.aries.blueprint/
>
> 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

---------------------------------------------
Freeman Fang

FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042











Re: Plans for release of aries blueprint 0.4.1?

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1

Regards
JB

On 04/12/2012 06:10 PM, Guillaume Nodet 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/org.apache.aries.blueprint/
>
> 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"<jo...@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
>>>
>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: EXTERNAL: Re: Plans for release of aries blueprint 0.4.1?

Posted by "Yonker, Jonathan" <jo...@lmco.com>.
I certainly can't comment on the developer implications, but I can say 
as a user of Karaf and Aries that this would be awesome. Right now, 
we're converting a lot of our blueprint files to spring because of some 
of the nastier bugs in 0.3.1. I would certainly appreciate getting these 
fixes into Karaf so we can go back to using blueprint for everything.

On 04/12/2012 09:10 AM, Guillaume Nodet 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/org.apache.aries.blueprint/
>
> 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"<jo...@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
>>>
>

Re: Plans for release of aries blueprint 0.4.1?

Posted by Daniel Kulp <da...@kulp.com>.
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 <gn...@gmail.com> wrote:
> > On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes <hu...@apache.org> wrote:
> >> On 12 April 2012 17:10, Guillaume Nodet <gn...@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


Re: Plans for release of aries blueprint 0.4.1?

Posted by Daniel Kulp <dk...@apache.org>.
(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 <gn...@gmail.com> wrote:
> > On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes <hu...@apache.org> wrote:
> >> On 12 April 2012 17:10, Guillaume Nodet <gn...@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

Re: Plans for release of aries blueprint 0.4.1?

Posted by Daniel Kulp <dk...@apache.org>.
(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 <gn...@gmail.com> wrote:
> > On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes <hu...@apache.org> wrote:
> >> On 12 April 2012 17:10, Guillaume Nodet <gn...@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

Re: Plans for release of aries blueprint 0.4.1?

Posted by Guillaume Nodet <gn...@gmail.com>.
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 ?

On Fri, Apr 13, 2012 at 20:30, Guillaume Nodet <gn...@gmail.com> wrote:

>
>
> On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes <hu...@apache.org> wrote:
>
>> On 12 April 2012 17:10, Guillaume Nodet <gn...@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/org.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
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: Plans for release of aries blueprint 0.4.1?

Posted by Guillaume Nodet <gn...@gmail.com>.
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 ?

On Fri, Apr 13, 2012 at 20:30, Guillaume Nodet <gn...@gmail.com> wrote:

>
>
> On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes <hu...@apache.org> wrote:
>
>> On 12 April 2012 17:10, Guillaume Nodet <gn...@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/org.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
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: Plans for release of aries blueprint 0.4.1?

Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes <hu...@apache.org> wrote:

> On 12 April 2012 17:10, Guillaume Nodet <gn...@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/org.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" <jo...@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

Re: Plans for release of aries blueprint 0.4.1?

Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Apr 13, 2012 at 18:33, Jeremy Hughes <hu...@apache.org> wrote:

> On 12 April 2012 17:10, Guillaume Nodet <gn...@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/org.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" <jo...@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

Re: Plans for release of aries blueprint 0.4.1?

Posted by Jeremy Hughes <hu...@apache.org>.
On 12 April 2012 17:10, Guillaume Nodet <gn...@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/org.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.

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" <jo...@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

Re: Plans for release of aries blueprint 0.4.1?

Posted by Freeman Fang <fr...@gmail.com>.
+1

Freeman
On 2012-4-13, at 上午12:10, Guillaume Nodet 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/org.apache.aries.blueprint/
>
> 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

---------------------------------------------
Freeman Fang

FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042











Re: Plans for release of aries blueprint 0.4.1?

Posted by Jeremy Hughes <hu...@apache.org>.
On 12 April 2012 17:10, Guillaume Nodet <gn...@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/org.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.

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" <jo...@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