jgoodyear wrote:
> 
> Hi Mike,
> 
>> Just so that I understand what we're talking about, because I haven't
>> seen
>> it articulated, is this the progression path being decided on?
>> 2.1.5 - Last maintenance release for the 2.1.x branch
>> 2.2.x - Still maintained (maintenance - bug fixes only)
>> 2.3.x - New features (development - new features allowed until release)
>> 3.0.0 - Next Major upgrade (development)
> 
> The 2.1.x branch will continue to receive patches as required, however
> once 2.3 and/or 3.0 branches are in release I would expect new 2.1.x
> patches to fade away. To my knowledge however we have not formally
> decided on a cut off point for branch support. The rest of the
> progression path appears to be about as I understand it to be at this
> time :)
> 
> Cheers,
> Jamie
> 
> On Tue, Apr 26, 2011 at 7:14 PM, mikevan <[email protected]>
> wrote:
>>
>> Johan Edstrom-2 wrote:
>>>
>>> +1 on dropping 1.5
>>>
>>>
>>> On Apr 17, 2011, at 9:34 PM, Freeman Fang wrote:
>>>
>>>>
>>>> On 2011-4-16, at 上午6:50, Guillaume Nodet wrote:
>>>>
>>>>> I kinda agree with David here.  IIRC, we decided to go for a 3.0
>>>>> mainly because of the switch to JDK 1.6.  So we should release that
>>>>> asap and add more features when they are ready in the following 3.1
>>>>> and 3.2 releases.   I'm not really in favor of maintaining two
>>>>> development versions (2.3 and 3.0) at the same time.
>>>>>
>>>>> However, having a 3.0 will certainly break most of the existing
>>>>> downstream projects, as they certainly use a [2.2,3.0) range for
>>>>> imports, meaning they won't deploy on the new 3.0, so we definitely
>>>>> not to do that unless we need.   So my position would be continue on
>>>>> 2.x and drop jdk 1.6 compatibility in 2.3.  I think other projects
>>>>> have done that too and I haven't heard many complaints.
>>>> Yeah, agree with Guillaume here.
>>>>
>>>> Since Camel 2.7(but not 3.0) drop jdk1.5 support so I believe it's ok
>>>> for
>>>> us to do same in karaf 2.3.
>>>>
>>>> Freeman
>>>>
>>>>>
>>>>>
>>>>> On Sat, Apr 16, 2011 at 00:39, Jamie G.
>>>>> <[email protected]>
>>>>> wrote:
>>>>>> It's a bit of a balancing act here deciding against a new 2.x branch
>>>>>> and a proper 3.0 release I agree. The general concern I think is
>>>>>> providing enough time for large number of major changes to appear in
>>>>>> version 3 trunk. Where major changes denote a large departure from
>>>>>> how
>>>>>> Karaf 2.x works. By making a 2.3 branch we give some breathing space
>>>>>> for 3.0 development to continue. That being said if the community is
>>>>>> more in favor of pushing up the 3.0 date instead of a 2.3 branch then
>>>>>> that could work as well.
>>>>>>
>>>>>> Jamie
>>>>>>
>>>>>> On Fri, Apr 15, 2011 at 7:41 PM, David Jencks
>>>>>> <[email protected]> wrote:
>>>>>>> I think an alternative would be to release 3.0.0 soon and put the
>>>>>>> new
>>>>>>> features on trunk.   I've found that its much easier to create new
>>>>>>> branches than to maintain them.  Could someone explain why a new
>>>>>>> branch is better than a soon 3.0.0 release?
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>>
>>>>>>> On Apr 15, 2011, at 8:50 AM, Jamie G. wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> There has been a number of discussions regarding trying out new
>>>>>>>> features on the 2.x branch while we are continuing to work towards
>>>>>>>> a
>>>>>>>> 3.0.x release, as such I think it may be worth discussing if we'd
>>>>>>>> like
>>>>>>>> to create a Karaf 2.3 branch?
>>>>>>>>
>>>>>>>> This branch would contain new features to the 2.x branch, and back
>>>>>>>> ported features from the 3.0 line. As this is a 2.x branch it would
>>>>>>>> continue to be JDK 1.5 & m2 compatible - we move to JKD 1.6 & m3 on
>>>>>>>> the Karaf 3.0 line.
>>>>>>>>
>>>>>>>> At this point I would presume the logical branch cut line would be
>>>>>>>> starting from the 2.2.1 tag once available? The 2.2.x line would
>>>>>>>> continue on in support mode, with 2.3.x collecting new features.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Jamie
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>> Connect at CamelOne May 24-26
>>>>> The Open Source Integration Conference
>>>>> http://camelone.com/
>>>>
>>>> ---------------------------------------------
>>>> Freeman Fang
>>>>
>>>> FuseSource
>>>> Email:[email protected]
>>>> Web: fusesource.com
>>>> Twitter: freemanfang
>>>> Blog: http://freemanfang.blogspot.com
>>>> Connect at CamelOne May 24-26
>>>> The Open Source Integration Conference
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> Personally, I'd like to see a release with the new and modified console
>> commands, as the developers on my team are ready to use them.  The ones I
>> worked on will work with 2.x, as they were written to work with 1.5.
>>
>> Agree with Guillaume though, we shouldn't introduce JDK 1.6 until 3.0.
>>  2.x
>> projects will likely want to make use of the 2.3 features, but requiring
>> 1.6
>> will break some of them.  A project using 2.x will see using 2.3 as the
>> natural upgrade path, making 2.3 not backwards compatible is not
>> intuitive.
>>
>> Just so that I understand what we're talking about, because I haven't
>> seen
>> it articulated, is this the progression path being decided on?
>> 2.1.5 - Last maintenance release for the 2.1.x branch
>> 2.2.x - Still maintained (maintenance - bug fixes only)
>> 2.3.x - New features (development - new features allowed until release)
>> 3.0.0 - Next Major upgrade (development)
>>
>> -----
>> Mike Van (aka karafman)
>> Karaf Team (Contributor)
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/PROPOSAL-Create-Karaf-2-3-x-branch-tp2825055p2867577.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
> 

Thanks Jamie.  By way of continuing the discussion, I'd like to ask that 
https://issues.apache.org/jira/browse/KARAF-560 KARAF-560  be included in
2.3.  If 2.2.1 is still collecting enhancements, I'd also ask that include
KARAF-560 as well.


-----
Mike Van (aka karafman)
Karaf Team (Contributor)
--
View this message in context: 
http://karaf.922171.n3.nabble.com/PROPOSAL-Create-Karaf-2-3-x-branch-tp2825055p2867917.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Reply via email to