Well, I can live with this proposal too, BUT then we should really limit the number of features planned for 3.0, move them to 3.1 and try to set a "date-limit" for 3.0. As discussed on other branches already there is a number of features which are not as "groundbraking" as davids kar changes, planed clustering and so on and for which I do not want to wait another 3-4 months...
Kind regards, Andreas On Sat, Apr 16, 2011 at 9:15 AM, Jean-Baptiste Onofré <[email protected]> wrote: > I second David around. > > We decides to prepare Karaf 3.0.0 for focus on JDK 1.6 support, maven 3 > support, etc. > > I propose: > 1/ now, to all focus on the 2.2.1 release (we are not so far) > 2/ move all 2.1.x and 2.2.x issues on 3.0.0 and focus on 3.0.0 to be able to > release a 3.0.0 version soon > > Regards > JB > > On 04/16/2011 12:11 AM, David Jencks 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 >> >
