You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by "Jamie G." <ja...@gmail.com> on 2010/10/13 16:43:17 UTC
Release planning
Hi All,
Now that Karaf 2.1.0 is available we have had some issues reported against
it, and as such we have begun to remediate those issues. This leads to the
important question of how do we want to wrap up these fixes? Should we pick
up the 2.1.x branch and prepare a 2.1.1 release or save all these fixes and
roll them into the 2.2.0 release?
Personally I think that if we do a 2.1.x maintenance release then we can
allow trunk (2.2.0) to continue along a little longer with more new feature
development.
As to the 2.2.0 release, we need to begin planning a target date for when
we'd like to cut a release candidate. I'd prefer to have this occur no later
than early December in order to avoid end of year holiday scheduling
conflicts.
Cheers,
Jamie
Re: Release planning
Posted by "Jamie G." <ja...@gmail.com>.
I've added a 2.1.1 release to the Karaf project versions in Jira.
On Wed, Oct 13, 2010 at 3:09 PM, Lars Heinemann <lh...@apache.org> wrote:
> I would go for 2.1.1 as it's mainly a bug fix release.
>
> Lars
>
>
> Am 13.10.2010 um 16:43 schrieb Jamie G.:
>
> > Hi All,
> >
> > Now that Karaf 2.1.0 is available we have had some issues reported
> against
> > it, and as such we have begun to remediate those issues. This leads to
> the
> > important question of how do we want to wrap up these fixes? Should we
> pick
> > up the 2.1.x branch and prepare a 2.1.1 release or save all these fixes
> and
> > roll them into the 2.2.0 release?
> >
> > Personally I think that if we do a 2.1.x maintenance release then we can
> > allow trunk (2.2.0) to continue along a little longer with more new
> feature
> > development.
> >
> > As to the 2.2.0 release, we need to begin planning a target date for when
> > we'd like to cut a release candidate. I'd prefer to have this occur no
> later
> > than early December in order to avoid end of year holiday scheduling
> > conflicts.
> >
> > Cheers,
> > Jamie
>
>
Re: Release planning
Posted by Lars Heinemann <lh...@apache.org>.
I would go for 2.1.1 as it's mainly a bug fix release.
Lars
Am 13.10.2010 um 16:43 schrieb Jamie G.:
> Hi All,
>
> Now that Karaf 2.1.0 is available we have had some issues reported against
> it, and as such we have begun to remediate those issues. This leads to the
> important question of how do we want to wrap up these fixes? Should we pick
> up the 2.1.x branch and prepare a 2.1.1 release or save all these fixes and
> roll them into the 2.2.0 release?
>
> Personally I think that if we do a 2.1.x maintenance release then we can
> allow trunk (2.2.0) to continue along a little longer with more new feature
> development.
>
> As to the 2.2.0 release, we need to begin planning a target date for when
> we'd like to cut a release candidate. I'd prefer to have this occur no later
> than early December in order to avoid end of year holiday scheduling
> conflicts.
>
> Cheers,
> Jamie
RE: Release planning
Posted by Łukasz Dywicki <lu...@code-house.org>.
I am not commiter yet, but if you would you can count my vote too. ;-)
Regards,
Lukasz
-----Original Message-----
From: Freeman Fang [mailto:freeman.fang@gmail.com]
Sent: Thursday, October 14, 2010 2:17 AM
To: dev@karaf.apache.org
Subject: Re: Release planning
+1 for 2.1.1
Best Regards
Freeman
On 2010-10-13, at 下午10:43, Jamie G. wrote:
> Hi All,
>
> Now that Karaf 2.1.0 is available we have had some issues reported
> against
> it, and as such we have begun to remediate those issues. This leads
> to the
> important question of how do we want to wrap up these fixes? Should
> we pick
> up the 2.1.x branch and prepare a 2.1.1 release or save all these
> fixes and
> roll them into the 2.2.0 release?
>
> Personally I think that if we do a 2.1.x maintenance release then we
> can
> allow trunk (2.2.0) to continue along a little longer with more new
> feature
> development.
>
> As to the 2.2.0 release, we need to begin planning a target date for
> when
> we'd like to cut a release candidate. I'd prefer to have this occur
> no later
> than early December in order to avoid end of year holiday scheduling
> conflicts.
>
> Cheers,
> Jamie
--
Freeman Fang
------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
Re: Release planning
Posted by Freeman Fang <fr...@gmail.com>.
+1 for 2.1.1
Best Regards
Freeman
On 2010-10-13, at 下午10:43, Jamie G. wrote:
> Hi All,
>
> Now that Karaf 2.1.0 is available we have had some issues reported
> against
> it, and as such we have begun to remediate those issues. This leads
> to the
> important question of how do we want to wrap up these fixes? Should
> we pick
> up the 2.1.x branch and prepare a 2.1.1 release or save all these
> fixes and
> roll them into the 2.2.0 release?
>
> Personally I think that if we do a 2.1.x maintenance release then we
> can
> allow trunk (2.2.0) to continue along a little longer with more new
> feature
> development.
>
> As to the 2.2.0 release, we need to begin planning a target date for
> when
> we'd like to cut a release candidate. I'd prefer to have this occur
> no later
> than early December in order to avoid end of year holiday scheduling
> conflicts.
>
> Cheers,
> Jamie
--
Freeman Fang
------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
Re: Release planning
Posted by Charles Moulliard <cm...@gmail.com>.
On 13/10/10 16:43, Jamie G. wrote:
> Hi All,
>
> Now that Karaf 2.1.0 is available we have had some issues reported against
> it, and as such we have begun to remediate those issues. This leads to the
> important question of how do we want to wrap up these fixes? Should we pick
> up the 2.1.x branch and prepare a 2.1.1 release or save all these fixes and
> roll them into the 2.2.0 release?
>
> Personally I think that if we do a 2.1.x maintenance release then we can
> allow trunk (2.2.0) to continue along a little longer with more new feature
> development.
>
> As to the 2.2.0 release, we need to begin planning a target date for when
> we'd like to cut a release candidate. I'd prefer to have this occur no later
> than early December in order to avoid end of year holiday scheduling
> conflicts.
>
> Cheers,
> Jamie
>
+1 for 2.1.1
Re: Release planning
Posted by Ioannis Canellos <io...@gmail.com>.
+1 for 2.1.1
On Wed, Oct 13, 2010 at 5:51 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> Hi Jamie,
>
> as we talk about bug fixes (not a lot of enhancement), I prefer to release
> 2.1.1.
>
> From my point of view, 2.2.0 should include bug fixes plus enhancement and
> new features.
>
> So
>
> +1 for 2.1.1
>
> Thanks
> Regards
> JB
>
>
> On 10/13/2010 04:43 PM, Jamie G. wrote:
>
>> Hi All,
>>
>> Now that Karaf 2.1.0 is available we have had some issues reported against
>> it, and as such we have begun to remediate those issues. This leads to the
>> important question of how do we want to wrap up these fixes? Should we
>> pick
>> up the 2.1.x branch and prepare a 2.1.1 release or save all these fixes
>> and
>> roll them into the 2.2.0 release?
>>
>> Personally I think that if we do a 2.1.x maintenance release then we can
>> allow trunk (2.2.0) to continue along a little longer with more new
>> feature
>> development.
>>
>> As to the 2.2.0 release, we need to begin planning a target date for when
>> we'd like to cut a release candidate. I'd prefer to have this occur no
>> later
>> than early December in order to avoid end of year holiday scheduling
>> conflicts.
>>
>> Cheers,
>> Jamie
>>
>>
--
*Ioannis Canellos*
http://iocanel.blogspot.com
Integration Engineer @ Upstream S.A. <http://www.upstreamsystems.com>
Re: Release planning
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Jamie,
as we talk about bug fixes (not a lot of enhancement), I prefer to
release 2.1.1.
From my point of view, 2.2.0 should include bug fixes plus enhancement
and new features.
So
+1 for 2.1.1
Thanks
Regards
JB
On 10/13/2010 04:43 PM, Jamie G. wrote:
> Hi All,
>
> Now that Karaf 2.1.0 is available we have had some issues reported against
> it, and as such we have begun to remediate those issues. This leads to the
> important question of how do we want to wrap up these fixes? Should we pick
> up the 2.1.x branch and prepare a 2.1.1 release or save all these fixes and
> roll them into the 2.2.0 release?
>
> Personally I think that if we do a 2.1.x maintenance release then we can
> allow trunk (2.2.0) to continue along a little longer with more new feature
> development.
>
> As to the 2.2.0 release, we need to begin planning a target date for when
> we'd like to cut a release candidate. I'd prefer to have this occur no later
> than early December in order to avoid end of year holiday scheduling
> conflicts.
>
> Cheers,
> Jamie
>
Re: Release planning
Posted by "Jamie G." <ja...@gmail.com>.
I've created the following Jira entries to track the currently planned
releases:
Apache Karaf 2.1.1:
https://issues.apache.org/jira/browse/KARAF-248
Apache Karaf 2.2.0:
https://issues.apache.org/jira/browse/KARAF-249
I'm more than happy to pick up RM duties on these releases. As to a timeline
for these releases I'm very open to suggestion. I'll concentrate first on
identifying issues for 2.1.1 inclusion while the 2.2.0 trunk continues.
On Thu, Oct 14, 2010 at 6:50 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Sounds like a good plan.
> I think we should also start thinking about what we want to include in 2.2,
> but we could also do a time-constrained release and just fix a date and
> release with whatever has been put in trunk (provided it's stable enough of
> course).
>
> On Wed, Oct 13, 2010 at 16:43, Jamie G. <ja...@gmail.com> wrote:
>
> > Hi All,
> >
> > Now that Karaf 2.1.0 is available we have had some issues reported
> against
> > it, and as such we have begun to remediate those issues. This leads to
> the
> > important question of how do we want to wrap up these fixes? Should we
> pick
> > up the 2.1.x branch and prepare a 2.1.1 release or save all these fixes
> and
> > roll them into the 2.2.0 release?
> >
> > Personally I think that if we do a 2.1.x maintenance release then we can
> > allow trunk (2.2.0) to continue along a little longer with more new
> feature
> > development.
> >
> > As to the 2.2.0 release, we need to begin planning a target date for when
> > we'd like to cut a release candidate. I'd prefer to have this occur no
> > later
> > than early December in order to avoid end of year holiday scheduling
> > conflicts.
> >
> > Cheers,
> > Jamie
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Release planning
Posted by Guillaume Nodet <gn...@gmail.com>.
Sounds like a good plan.
I think we should also start thinking about what we want to include in 2.2,
but we could also do a time-constrained release and just fix a date and
release with whatever has been put in trunk (provided it's stable enough of
course).
On Wed, Oct 13, 2010 at 16:43, Jamie G. <ja...@gmail.com> wrote:
> Hi All,
>
> Now that Karaf 2.1.0 is available we have had some issues reported against
> it, and as such we have begun to remediate those issues. This leads to the
> important question of how do we want to wrap up these fixes? Should we pick
> up the 2.1.x branch and prepare a 2.1.1 release or save all these fixes and
> roll them into the 2.2.0 release?
>
> Personally I think that if we do a 2.1.x maintenance release then we can
> allow trunk (2.2.0) to continue along a little longer with more new feature
> development.
>
> As to the 2.2.0 release, we need to begin planning a target date for when
> we'd like to cut a release candidate. I'd prefer to have this occur no
> later
> than early December in order to avoid end of year holiday scheduling
> conflicts.
>
> Cheers,
> Jamie
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com