You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2013/03/10 18:58:58 UTC
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Hi all,
I've created the karaf-2.x branch, and updated the POM version to
2.4.0-SNAPSHOT.
I'm testing it now, and I gonna work on this branch tonight.
If it's OK for all:
- I will announce Karaf 2.3.x and 2.2.x branches as in maintenance mode:
so no new features on those branches, just critical bug fixes
- I propose to wait a first 2.4.0 to set 2.2.x as EOL
On the other hand, I will discuss with Jamie tomorrow to cut off a first
3.0.0.RC1 (I fixed a couple of issue, but in order to have some feedback
from "test" users, I think we should provide a first RC1).
WDYT ?
Regards
JB
On 02/07/2013 04:33 PM, jb@nanthrax.net wrote:
> Hi all,
>
> following a discussion started a couple of weeks ago, just an update
> about Karaf branches and releases:
>
> - karaf-2.x: I'm going to create this branch asap (let say tonight or
> tomorrow). This branch will be the codebase for Karaf 2.4, Karaf 2.5,
> etc. This branch will be created starting from the current karaf-2.3.x one.
> - karaf-2.3.x: this branch stays as it is and it becomes
> *MAINTENANCE/GA* branch. It means no new features, no new commands, only
> bug fixes. I will remove new features from this branch (for instance
> shell:date command, etc) to respect this *MAINTENANCE/GA* "mode". I will
> look for new features or improvements using Jira.
> - karaf-2.2.x: as soon as Karaf 2.4.0 will be released (on the karaf-2.x
> branch), this branch will go in EOL mode (and an announcement will be
> send to the users).
>
> In terms of releases planning:
> - Karaf 2.3.1 is waiting for Aries JMX 1.1.1 and Pax Web 1.1.12
> releases. I will tackle the Pax Web release with Achim, and ping Dan
> about the Aries release.
> - Karaf 3.0.0.RC1 is waiting for Aries JMX 1.1.1 release. It would be
> cool to fix a couple of issues around sub-shell here, but it's not
> blocker for RC1 IMHO.
> - we can plan to cut off Karaf 2.4 in 6 weeks after 2.3.1.
> - I propose a Karaf 2.2.11 with latest bug fixes before the switch to
> EOL mode.
>
> WDYT ?
>
> Thanks,
> Regards
> JB
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by Christian Schneider <ch...@die-schneider.net>.
That sounds good. I think we should agree on a common best practice in
the karaf dev list and document it on the web site.
Christian
On 13.03.2013 12:11, Guillaume Nodet wrote:
> As I said, I think we can live with only backporting to the latest 2.x
> maintenance branch.
> When there's a need for an older bug fix release, we can cherry-pick the
> changes from that branch.
> It needs to be a community decision so that we know what we're doing and
> not taken by surprise when preparing a release on an old branch.
>
>
> On Wed, Mar 13, 2013 at 12:07 PM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> I agree that we should allow people to backport features to 2.x. This
>> allows companies to support
>> older branches for a longer time than even our community release cycles.
>> The problem is that as soon as a branch is there it is kind of an
>> obligation for all developers to backport at least fixes.
>>
>> Christian
>>
>>
>> On 13.03.2013 11:32, Guillaume Nodet wrote:
>>
>>> I think we already discussed to not add new features to micro branches and
>>> the obvious reason is to keep them stable.
>>>
>>> I agree we have limited resources, but backporting fixes amongst 2.x
>>> branches is mostly painless and usually comes down to a git cherry-pick,
>>> compared to backporting from trunk to 2.x, so the added work is limited.
>>> In addition, we could decide to backport only to 2.3.x and do additional
>>> backport to 2.2.x when there's a need for a 2.2.x release.
>>> Afaik, there's no current plan for a 2.4.0 (at least, I don't have any
>>> yet), but i see some minor useful stuff that could be done: some major
>>> dependencies upgrade could be useful : felix 4.2, pax-web 3 ... There's
>>> also the jbosgi integration which may come in the coming months. And
>>> support for scr or cdi.
>>>
>>> Anyway, one thing we should never prevent is for anyone to get involved
>>> and
>>> work on older versions if they need for various reasons. So which
>>> branches
>>> we support or eol are just guidelines imho.
>>>
>>> On Wed, Mar 13, 2013 at 10:20 AM, Christian Schneider <
>>> chris@die-schneider.net> wrote:
>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Mar 13, 2013 at 12:20 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> Agree, but it's mostly possible inside 2.x branches (the codebase has
> changed on trunk).
>
> I don't want to consider "company maintenance" here, just community.
>
Agreed, though our users and our customers need are certainly the same to
some degree.
>
> From a community perspective, I think we have to maintain max 2 branches.
>
I'd rather keep trunk and 2.3.x. It should be easier to merge from 2.3.x
to 2.x than the opposite.
>
> Regards
> JB
>
>
> On 03/13/2013 12:11 PM, Guillaume Nodet wrote:
>
>> As I said, I think we can live with only backporting to the latest 2.x
>> maintenance branch.
>> When there's a need for an older bug fix release, we can cherry-pick the
>> changes from that branch.
>> It needs to be a community decision so that we know what we're doing and
>> not taken by surprise when preparing a release on an old branch.
>>
>>
>> On Wed, Mar 13, 2013 at 12:07 PM, Christian Schneider <
>> chris@die-schneider.net> wrote:
>>
>> I agree that we should allow people to backport features to 2.x. This
>>> allows companies to support
>>> older branches for a longer time than even our community release cycles.
>>> The problem is that as soon as a branch is there it is kind of an
>>> obligation for all developers to backport at least fixes.
>>>
>>> Christian
>>>
>>>
>>> On 13.03.2013 11:32, Guillaume Nodet wrote:
>>>
>>> I think we already discussed to not add new features to micro branches
>>>> and
>>>> the obvious reason is to keep them stable.
>>>>
>>>> I agree we have limited resources, but backporting fixes amongst 2.x
>>>> branches is mostly painless and usually comes down to a git cherry-pick,
>>>> compared to backporting from trunk to 2.x, so the added work is limited.
>>>> In addition, we could decide to backport only to 2.3.x and do
>>>> additional
>>>> backport to 2.2.x when there's a need for a 2.2.x release.
>>>> Afaik, there's no current plan for a 2.4.0 (at least, I don't have any
>>>> yet), but i see some minor useful stuff that could be done: some major
>>>> dependencies upgrade could be useful : felix 4.2, pax-web 3 ... There's
>>>> also the jbosgi integration which may come in the coming months. And
>>>> support for scr or cdi.
>>>>
>>>> Anyway, one thing we should never prevent is for anyone to get involved
>>>> and
>>>> work on older versions if they need for various reasons. So which
>>>> branches
>>>> we support or eol are just guidelines imho.
>>>>
>>>> On Wed, Mar 13, 2013 at 10:20 AM, Christian Schneider <
>>>> chris@die-schneider.net> wrote:
>>>>
>>>>
>>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Agree, but it's mostly possible inside 2.x branches (the codebase has
changed on trunk).
I don't want to consider "company maintenance" here, just community.
From a community perspective, I think we have to maintain max 2 branches.
Regards
JB
On 03/13/2013 12:11 PM, Guillaume Nodet wrote:
> As I said, I think we can live with only backporting to the latest 2.x
> maintenance branch.
> When there's a need for an older bug fix release, we can cherry-pick the
> changes from that branch.
> It needs to be a community decision so that we know what we're doing and
> not taken by surprise when preparing a release on an old branch.
>
>
> On Wed, Mar 13, 2013 at 12:07 PM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> I agree that we should allow people to backport features to 2.x. This
>> allows companies to support
>> older branches for a longer time than even our community release cycles.
>> The problem is that as soon as a branch is there it is kind of an
>> obligation for all developers to backport at least fixes.
>>
>> Christian
>>
>>
>> On 13.03.2013 11:32, Guillaume Nodet wrote:
>>
>>> I think we already discussed to not add new features to micro branches and
>>> the obvious reason is to keep them stable.
>>>
>>> I agree we have limited resources, but backporting fixes amongst 2.x
>>> branches is mostly painless and usually comes down to a git cherry-pick,
>>> compared to backporting from trunk to 2.x, so the added work is limited.
>>> In addition, we could decide to backport only to 2.3.x and do additional
>>> backport to 2.2.x when there's a need for a 2.2.x release.
>>> Afaik, there's no current plan for a 2.4.0 (at least, I don't have any
>>> yet), but i see some minor useful stuff that could be done: some major
>>> dependencies upgrade could be useful : felix 4.2, pax-web 3 ... There's
>>> also the jbosgi integration which may come in the coming months. And
>>> support for scr or cdi.
>>>
>>> Anyway, one thing we should never prevent is for anyone to get involved
>>> and
>>> work on older versions if they need for various reasons. So which
>>> branches
>>> we support or eol are just guidelines imho.
>>>
>>> On Wed, Mar 13, 2013 at 10:20 AM, Christian Schneider <
>>> chris@die-schneider.net> wrote:
>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by Guillaume Nodet <gn...@gmail.com>.
As I said, I think we can live with only backporting to the latest 2.x
maintenance branch.
When there's a need for an older bug fix release, we can cherry-pick the
changes from that branch.
It needs to be a community decision so that we know what we're doing and
not taken by surprise when preparing a release on an old branch.
On Wed, Mar 13, 2013 at 12:07 PM, Christian Schneider <
chris@die-schneider.net> wrote:
> I agree that we should allow people to backport features to 2.x. This
> allows companies to support
> older branches for a longer time than even our community release cycles.
> The problem is that as soon as a branch is there it is kind of an
> obligation for all developers to backport at least fixes.
>
> Christian
>
>
> On 13.03.2013 11:32, Guillaume Nodet wrote:
>
>> I think we already discussed to not add new features to micro branches and
>> the obvious reason is to keep them stable.
>>
>> I agree we have limited resources, but backporting fixes amongst 2.x
>> branches is mostly painless and usually comes down to a git cherry-pick,
>> compared to backporting from trunk to 2.x, so the added work is limited.
>> In addition, we could decide to backport only to 2.3.x and do additional
>> backport to 2.2.x when there's a need for a 2.2.x release.
>> Afaik, there's no current plan for a 2.4.0 (at least, I don't have any
>> yet), but i see some minor useful stuff that could be done: some major
>> dependencies upgrade could be useful : felix 4.2, pax-web 3 ... There's
>> also the jbosgi integration which may come in the coming months. And
>> support for scr or cdi.
>>
>> Anyway, one thing we should never prevent is for anyone to get involved
>> and
>> work on older versions if they need for various reasons. So which
>> branches
>> we support or eol are just guidelines imho.
>>
>> On Wed, Mar 13, 2013 at 10:20 AM, Christian Schneider <
>> chris@die-schneider.net> wrote:
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by Christian Schneider <ch...@die-schneider.net>.
I agree that we should allow people to backport features to 2.x. This
allows companies to support
older branches for a longer time than even our community release cycles.
The problem is that as soon as a branch is there it is kind of an
obligation for all developers to backport at least fixes.
Christian
On 13.03.2013 11:32, Guillaume Nodet wrote:
> I think we already discussed to not add new features to micro branches and
> the obvious reason is to keep them stable.
>
> I agree we have limited resources, but backporting fixes amongst 2.x
> branches is mostly painless and usually comes down to a git cherry-pick,
> compared to backporting from trunk to 2.x, so the added work is limited.
> In addition, we could decide to backport only to 2.3.x and do additional
> backport to 2.2.x when there's a need for a 2.2.x release.
> Afaik, there's no current plan for a 2.4.0 (at least, I don't have any
> yet), but i see some minor useful stuff that could be done: some major
> dependencies upgrade could be useful : felix 4.2, pax-web 3 ... There's
> also the jbosgi integration which may come in the coming months. And
> support for scr or cdi.
>
> Anyway, one thing we should never prevent is for anyone to get involved and
> work on older versions if they need for various reasons. So which branches
> we support or eol are just guidelines imho.
>
> On Wed, Mar 13, 2013 at 10:20 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by Guillaume Nodet <gn...@gmail.com>.
I think we already discussed to not add new features to micro branches and
the obvious reason is to keep them stable.
I agree we have limited resources, but backporting fixes amongst 2.x
branches is mostly painless and usually comes down to a git cherry-pick,
compared to backporting from trunk to 2.x, so the added work is limited.
In addition, we could decide to backport only to 2.3.x and do additional
backport to 2.2.x when there's a need for a 2.2.x release.
Afaik, there's no current plan for a 2.4.0 (at least, I don't have any
yet), but i see some minor useful stuff that could be done: some major
dependencies upgrade could be useful : felix 4.2, pax-web 3 ... There's
also the jbosgi integration which may come in the coming months. And
support for scr or cdi.
Anyway, one thing we should never prevent is for anyone to get involved and
work on older versions if they need for various reasons. So which branches
we support or eol are just guidelines imho.
On Wed, Mar 13, 2013 at 10:20 AM, Christian Schneider <
chris@die-schneider.net> wrote:
> Honestly I would prefer to not do a 2.4.x branch at all. As long as we do
> not abandon a branch it would mean that we have 4 active branches
> 2.2.x
> 2.3.x
> 2.4.x
> trunk
>
> Looking at the very limited developer resources we have this is very
> difficult to maintain.
>
> So I propose instead of doing the 2.4.x branch we rather allow some
> feature changes in 2.3.x like we did in 2.2.x. I general I think we should
> keep feature changes in 2.3.x to the minimum and rather concentrate on 3.x.
>
> Christian
>
>
>
> On 13.03.2013 02:50, Guillaume Nodet wrote:
>
>> Sorry to jump on late, but is there any need to change the branch naming
>> scheme on 2.x now ?
>> I was quite happy with 2.2.x, 2.3.x scheme so far, and kinda fail to see
>> how the new one is supposed to be used.
>>
>> Is the plan to create a 2.4.x maintenance branch once 2.4.0 would be out,
>> or maybe just before cutting the release ?
>> It's no big deal, but I fail to see the purpose for this change ...
>>
>>
>> On Sun, Mar 10, 2013 at 6:58 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>> >wrote:
>>
>> Hi all,
>>>
>>> I've created the karaf-2.x branch, and updated the POM version to
>>> 2.4.0-SNAPSHOT.
>>>
>>> I'm testing it now, and I gonna work on this branch tonight.
>>>
>>> If it's OK for all:
>>> - I will announce Karaf 2.3.x and 2.2.x branches as in maintenance mode:
>>> so no new features on those branches, just critical bug fixes
>>> - I propose to wait a first 2.4.0 to set 2.2.x as EOL
>>>
>>> On the other hand, I will discuss with Jamie tomorrow to cut off a first
>>> 3.0.0.RC1 (I fixed a couple of issue, but in order to have some feedback
>>> from "test" users, I think we should provide a first RC1).
>>>
>>> WDYT ?
>>>
>>>
>>> Regards
>>> JB
>>>
>>> On 02/07/2013 04:33 PM, jb@nanthrax.net wrote:
>>>
>>> Hi all,
>>>>
>>>> following a discussion started a couple of weeks ago, just an update
>>>> about Karaf branches and releases:
>>>>
>>>> - karaf-2.x: I'm going to create this branch asap (let say tonight or
>>>> tomorrow). This branch will be the codebase for Karaf 2.4, Karaf 2.5,
>>>> etc. This branch will be created starting from the current karaf-2.3.x
>>>> one.
>>>> - karaf-2.3.x: this branch stays as it is and it becomes
>>>> *MAINTENANCE/GA* branch. It means no new features, no new commands, only
>>>> bug fixes. I will remove new features from this branch (for instance
>>>> shell:date command, etc) to respect this *MAINTENANCE/GA* "mode". I will
>>>> look for new features or improvements using Jira.
>>>> - karaf-2.2.x: as soon as Karaf 2.4.0 will be released (on the karaf-2.x
>>>> branch), this branch will go in EOL mode (and an announcement will be
>>>> send to the users).
>>>>
>>>> In terms of releases planning:
>>>> - Karaf 2.3.1 is waiting for Aries JMX 1.1.1 and Pax Web 1.1.12
>>>> releases. I will tackle the Pax Web release with Achim, and ping Dan
>>>> about the Aries release.
>>>> - Karaf 3.0.0.RC1 is waiting for Aries JMX 1.1.1 release. It would be
>>>> cool to fix a couple of issues around sub-shell here, but it's not
>>>> blocker for RC1 IMHO.
>>>> - we can plan to cut off Karaf 2.4 in 6 weeks after 2.3.1.
>>>> - I propose a Karaf 2.2.11 with latest bug fixes before the switch to
>>>> EOL mode.
>>>>
>>>> WDYT ?
>>>>
>>>> Thanks,
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by Christian Schneider <ch...@die-schneider.net>.
Honestly I would prefer to not do a 2.4.x branch at all. As long as we
do not abandon a branch it would mean that we have 4 active branches
2.2.x
2.3.x
2.4.x
trunk
Looking at the very limited developer resources we have this is very
difficult to maintain.
So I propose instead of doing the 2.4.x branch we rather allow some
feature changes in 2.3.x like we did in 2.2.x. I general I think we
should keep feature changes in 2.3.x to the minimum and rather
concentrate on 3.x.
Christian
On 13.03.2013 02:50, Guillaume Nodet wrote:
> Sorry to jump on late, but is there any need to change the branch naming
> scheme on 2.x now ?
> I was quite happy with 2.2.x, 2.3.x scheme so far, and kinda fail to see
> how the new one is supposed to be used.
>
> Is the plan to create a 2.4.x maintenance branch once 2.4.0 would be out,
> or maybe just before cutting the release ?
> It's no big deal, but I fail to see the purpose for this change ...
>
>
> On Sun, Mar 10, 2013 at 6:58 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>
>> Hi all,
>>
>> I've created the karaf-2.x branch, and updated the POM version to
>> 2.4.0-SNAPSHOT.
>>
>> I'm testing it now, and I gonna work on this branch tonight.
>>
>> If it's OK for all:
>> - I will announce Karaf 2.3.x and 2.2.x branches as in maintenance mode:
>> so no new features on those branches, just critical bug fixes
>> - I propose to wait a first 2.4.0 to set 2.2.x as EOL
>>
>> On the other hand, I will discuss with Jamie tomorrow to cut off a first
>> 3.0.0.RC1 (I fixed a couple of issue, but in order to have some feedback
>> from "test" users, I think we should provide a first RC1).
>>
>> WDYT ?
>>
>>
>> Regards
>> JB
>>
>> On 02/07/2013 04:33 PM, jb@nanthrax.net wrote:
>>
>>> Hi all,
>>>
>>> following a discussion started a couple of weeks ago, just an update
>>> about Karaf branches and releases:
>>>
>>> - karaf-2.x: I'm going to create this branch asap (let say tonight or
>>> tomorrow). This branch will be the codebase for Karaf 2.4, Karaf 2.5,
>>> etc. This branch will be created starting from the current karaf-2.3.x
>>> one.
>>> - karaf-2.3.x: this branch stays as it is and it becomes
>>> *MAINTENANCE/GA* branch. It means no new features, no new commands, only
>>> bug fixes. I will remove new features from this branch (for instance
>>> shell:date command, etc) to respect this *MAINTENANCE/GA* "mode". I will
>>> look for new features or improvements using Jira.
>>> - karaf-2.2.x: as soon as Karaf 2.4.0 will be released (on the karaf-2.x
>>> branch), this branch will go in EOL mode (and an announcement will be
>>> send to the users).
>>>
>>> In terms of releases planning:
>>> - Karaf 2.3.1 is waiting for Aries JMX 1.1.1 and Pax Web 1.1.12
>>> releases. I will tackle the Pax Web release with Achim, and ping Dan
>>> about the Aries release.
>>> - Karaf 3.0.0.RC1 is waiting for Aries JMX 1.1.1 release. It would be
>>> cool to fix a couple of issues around sub-shell here, but it's not
>>> blocker for RC1 IMHO.
>>> - we can plan to cut off Karaf 2.4 in 6 weeks after 2.3.1.
>>> - I propose a Karaf 2.2.11 with latest bug fixes before the switch to
>>> EOL mode.
>>>
>>> WDYT ?
>>>
>>> Thanks,
>>> Regards
>>> JB
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Guillaume,
the plan is to create karaf-2.4.x when it's necessary.
The purpose is to avoid to create a lot of "micro" version, and more use
"minor" version.
A Karaf 2.4.1 will never supposed to be released. However, if we have a
critical set of bug fixes that can't wait 2.5.0, in that case, we will
create karaf-2.4.x to put in it.
Regards
JB
On 03/13/2013 02:50 AM, Guillaume Nodet wrote:
> Sorry to jump on late, but is there any need to change the branch naming
> scheme on 2.x now ?
> I was quite happy with 2.2.x, 2.3.x scheme so far, and kinda fail to see
> how the new one is supposed to be used.
>
> Is the plan to create a 2.4.x maintenance branch once 2.4.0 would be out,
> or maybe just before cutting the release ?
> It's no big deal, but I fail to see the purpose for this change ...
>
>
> On Sun, Mar 10, 2013 at 6:58 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>
>> Hi all,
>>
>> I've created the karaf-2.x branch, and updated the POM version to
>> 2.4.0-SNAPSHOT.
>>
>> I'm testing it now, and I gonna work on this branch tonight.
>>
>> If it's OK for all:
>> - I will announce Karaf 2.3.x and 2.2.x branches as in maintenance mode:
>> so no new features on those branches, just critical bug fixes
>> - I propose to wait a first 2.4.0 to set 2.2.x as EOL
>>
>> On the other hand, I will discuss with Jamie tomorrow to cut off a first
>> 3.0.0.RC1 (I fixed a couple of issue, but in order to have some feedback
>> from "test" users, I think we should provide a first RC1).
>>
>> WDYT ?
>>
>>
>> Regards
>> JB
>>
>> On 02/07/2013 04:33 PM, jb@nanthrax.net wrote:
>>
>>> Hi all,
>>>
>>> following a discussion started a couple of weeks ago, just an update
>>> about Karaf branches and releases:
>>>
>>> - karaf-2.x: I'm going to create this branch asap (let say tonight or
>>> tomorrow). This branch will be the codebase for Karaf 2.4, Karaf 2.5,
>>> etc. This branch will be created starting from the current karaf-2.3.x
>>> one.
>>> - karaf-2.3.x: this branch stays as it is and it becomes
>>> *MAINTENANCE/GA* branch. It means no new features, no new commands, only
>>> bug fixes. I will remove new features from this branch (for instance
>>> shell:date command, etc) to respect this *MAINTENANCE/GA* "mode". I will
>>> look for new features or improvements using Jira.
>>> - karaf-2.2.x: as soon as Karaf 2.4.0 will be released (on the karaf-2.x
>>> branch), this branch will go in EOL mode (and an announcement will be
>>> send to the users).
>>>
>>> In terms of releases planning:
>>> - Karaf 2.3.1 is waiting for Aries JMX 1.1.1 and Pax Web 1.1.12
>>> releases. I will tackle the Pax Web release with Achim, and ping Dan
>>> about the Aries release.
>>> - Karaf 3.0.0.RC1 is waiting for Aries JMX 1.1.1 release. It would be
>>> cool to fix a couple of issues around sub-shell here, but it's not
>>> blocker for RC1 IMHO.
>>> - we can plan to cut off Karaf 2.4 in 6 weeks after 2.3.1.
>>> - I propose a Karaf 2.2.11 with latest bug fixes before the switch to
>>> EOL mode.
>>>
>>> WDYT ?
>>>
>>> Thanks,
>>> Regards
>>> JB
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by Guillaume Nodet <gn...@gmail.com>.
Sorry to jump on late, but is there any need to change the branch naming
scheme on 2.x now ?
I was quite happy with 2.2.x, 2.3.x scheme so far, and kinda fail to see
how the new one is supposed to be used.
Is the plan to create a 2.4.x maintenance branch once 2.4.0 would be out,
or maybe just before cutting the release ?
It's no big deal, but I fail to see the purpose for this change ...
On Sun, Mar 10, 2013 at 6:58 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> Hi all,
>
> I've created the karaf-2.x branch, and updated the POM version to
> 2.4.0-SNAPSHOT.
>
> I'm testing it now, and I gonna work on this branch tonight.
>
> If it's OK for all:
> - I will announce Karaf 2.3.x and 2.2.x branches as in maintenance mode:
> so no new features on those branches, just critical bug fixes
> - I propose to wait a first 2.4.0 to set 2.2.x as EOL
>
> On the other hand, I will discuss with Jamie tomorrow to cut off a first
> 3.0.0.RC1 (I fixed a couple of issue, but in order to have some feedback
> from "test" users, I think we should provide a first RC1).
>
> WDYT ?
>
>
> Regards
> JB
>
> On 02/07/2013 04:33 PM, jb@nanthrax.net wrote:
>
>> Hi all,
>>
>> following a discussion started a couple of weeks ago, just an update
>> about Karaf branches and releases:
>>
>> - karaf-2.x: I'm going to create this branch asap (let say tonight or
>> tomorrow). This branch will be the codebase for Karaf 2.4, Karaf 2.5,
>> etc. This branch will be created starting from the current karaf-2.3.x
>> one.
>> - karaf-2.3.x: this branch stays as it is and it becomes
>> *MAINTENANCE/GA* branch. It means no new features, no new commands, only
>> bug fixes. I will remove new features from this branch (for instance
>> shell:date command, etc) to respect this *MAINTENANCE/GA* "mode". I will
>> look for new features or improvements using Jira.
>> - karaf-2.2.x: as soon as Karaf 2.4.0 will be released (on the karaf-2.x
>> branch), this branch will go in EOL mode (and an announcement will be
>> send to the users).
>>
>> In terms of releases planning:
>> - Karaf 2.3.1 is waiting for Aries JMX 1.1.1 and Pax Web 1.1.12
>> releases. I will tackle the Pax Web release with Achim, and ping Dan
>> about the Aries release.
>> - Karaf 3.0.0.RC1 is waiting for Aries JMX 1.1.1 release. It would be
>> cool to fix a couple of issues around sub-shell here, but it's not
>> blocker for RC1 IMHO.
>> - we can plan to cut off Karaf 2.4 in 6 weeks after 2.3.1.
>> - I propose a Karaf 2.2.11 with latest bug fixes before the switch to
>> EOL mode.
>>
>> WDYT ?
>>
>> Thanks,
>> Regards
>> JB
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [UPDATE] Karaf branches and features in Karaf 2.3.x
Posted by "Jamie G." <ja...@gmail.com>.
Sounds good to me :)
Cheers,
Jamie
On Sun, Mar 10, 2013 at 3:28 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi all,
>
> I've created the karaf-2.x branch, and updated the POM version to
> 2.4.0-SNAPSHOT.
>
> I'm testing it now, and I gonna work on this branch tonight.
>
> If it's OK for all:
> - I will announce Karaf 2.3.x and 2.2.x branches as in maintenance mode: so
> no new features on those branches, just critical bug fixes
> - I propose to wait a first 2.4.0 to set 2.2.x as EOL
>
> On the other hand, I will discuss with Jamie tomorrow to cut off a first
> 3.0.0.RC1 (I fixed a couple of issue, but in order to have some feedback
> from "test" users, I think we should provide a first RC1).
>
> WDYT ?
>
>
> Regards
> JB
>
> On 02/07/2013 04:33 PM, jb@nanthrax.net wrote:
>>
>> Hi all,
>>
>> following a discussion started a couple of weeks ago, just an update
>> about Karaf branches and releases:
>>
>> - karaf-2.x: I'm going to create this branch asap (let say tonight or
>> tomorrow). This branch will be the codebase for Karaf 2.4, Karaf 2.5,
>> etc. This branch will be created starting from the current karaf-2.3.x
>> one.
>> - karaf-2.3.x: this branch stays as it is and it becomes
>> *MAINTENANCE/GA* branch. It means no new features, no new commands, only
>> bug fixes. I will remove new features from this branch (for instance
>> shell:date command, etc) to respect this *MAINTENANCE/GA* "mode". I will
>> look for new features or improvements using Jira.
>> - karaf-2.2.x: as soon as Karaf 2.4.0 will be released (on the karaf-2.x
>> branch), this branch will go in EOL mode (and an announcement will be
>> send to the users).
>>
>> In terms of releases planning:
>> - Karaf 2.3.1 is waiting for Aries JMX 1.1.1 and Pax Web 1.1.12
>> releases. I will tackle the Pax Web release with Achim, and ping Dan
>> about the Aries release.
>> - Karaf 3.0.0.RC1 is waiting for Aries JMX 1.1.1 release. It would be
>> cool to fix a couple of issues around sub-shell here, but it's not
>> blocker for RC1 IMHO.
>> - we can plan to cut off Karaf 2.4 in 6 weeks after 2.3.1.
>> - I propose a Karaf 2.2.11 with latest bug fixes before the switch to
>> EOL mode.
>>
>> WDYT ?
>>
>> Thanks,
>> Regards
>> JB
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com