On Wed, Mar 13, 2013 at 12:20 PM, Jean-Baptiste Onofré <j...@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 < >> ch...@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 < >>>> ch...@die-schneider.net> wrote: >>>> >>>> >>>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >>> >>> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
