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 < [email protected]> 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é <[email protected] >> >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, [email protected] 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é >>> [email protected] >>> 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: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
