On Tue, Apr 26, 2011 at 23:44, 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. >
I thought I said quite the opposite. I wonder how many people are still using jdk 1.5 in production though. Given JDK 1.5 has been EOSL end of 2009, I think that putting a project in production with 1.5 is not really safe and I would hope most people would have upgraded to 1.6 to be able to use a supported version. If that's the case, I'd really rather drop 3.0 and release 2.3 has soon as trunk is stable with support for JDK 1.6 and maven 3. If we look at the Camel survey that was conducted one year ago (http://camel.apache.org/camel-30-roadmap.data/camel-survey-2010.pdf), 85% were using JDK 1.6 and still 25% were using JDK 1.5. That's actually quite a big number, but I expect that number to go down and I doubt new projects will be buit on top of JDK 1.5. The big problem I have with 3.0 is that given we don't use independant numbers for our package versions, this means all downstream projects will be broken because they usually import [2.2,3) for Karaf. I'm much more concerned with that rather than not allowing a small fraction of our users to upgrade their prod system using JDK 1.5 on to 2.3. Last, I'd also rather slightly relax our rule and allow a few selected enhancements to be in 2.2 rather than the above. That said, supporting JDK 1.5 is not really a big problem for us. I found this plugin that we should leverage (http://mojo.codehaus.org/animal-sniffer-maven-plugin/) as it allow testing against JDK 1.5 methods (it would avoid using methods not defined on JDK 1.6 that the compiler don't really check). -- 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/
