Yeah, it does allow for a cleaner break (similar to when SMX 4 started up during SMX 3 development).
Perhaps we should consider polling our user base as to the importance of JDK 1.5 compatibility? That could help in determining how long into the future we could potentially need to maintain the current JDK 1.5 compatible 2.x line. I think that if we were to move to JDK 1.6+ support only as of version X.Y.Z then we would need to give plenty of long term heads up regarding such a change. 2011/1/4 Andreas Pieber <[email protected]>: > Yep, I'm completely of your opinion belonging the 2.2.x JDK releases. > > But I think 2.3.x wouldn't be enough. I'm afraid that industry will > demand feature releases of karaf for at least another year or two and > a 2.3.x line for jdk6 will prevent us from doing feature releases > based on jdk5; a 3.x line wouldn't. > > 2011/1/5 Jamie G. <[email protected]>: >> Perhaps a 2.3.x line? Departing from JDK 1.5 support would represent >> enough of a change IMHO to require some sort of higher version number >> change. I'm not too much of a fan of having separate 2.2.x JDK 1.5+ >> and JDK 1.6+ kits... would just lead to confusion in deployment and >> debugging. >> >> 2011/1/4 Andreas Pieber <[email protected]>: >>> Actually I think we should name it karaf-2.x.x, but otherwise yes. At >>> least I would prefer this solution compared to a jdk6-branch since >>> 3.0.0 will allow us more freedom from a logical point of view (IMHO) >>> >>> kind regards, >>> andreas >>> >>> 2011/1/5 Jamie G. <[email protected]>: >>>> So just to be clear, you are proposing we branch our current mainline >>>> to 2.2.x and then have main become 3.0.x (which will JDK 1.6 going >>>> forward)? >>>> >>>> >>>> 2011/1/4 Andreas Pieber <[email protected]>: >>>>> The problem is that in industry still many ppl use jdk1.5. What I >>>>> would like is to branch off karaf-2.x.x and update karafs version to >>>>> 3.0.0 in trunk. I think the mainlines we'll be identical enough to >>>>> support both versions easily for at least another year or two (by >>>>> simply cherry-picking commits from trunk to 2.2.x) and simply do not >>>>> implement all features on both branches (e.g. KARAF-53 for 3.x.x >>>>> only). >>>>> >>>>> kind regards, >>>>> andreas >>>>> >>>>> 2011/1/4 Łukasz Dywicki <[email protected]>: >>>>>> Hi all, >>>>>> >>>>>> Some time ago I created issue KARAF-328 which is sticky card about JVM >>>>>> version policy. >>>>>> >>>>>> >>>>>> >>>>>> Now I am a bit confused because I would like get rid XML parsing from >>>>>> feature service and switch it to JAXB while working on KARAF-53. I know >>>>>> that >>>>>> build is made on JVM 1.5 and this change will broke capability with older >>>>>> virtual machines. I wouldn't force anyone to upgrade but moving to new >>>>>> JVM >>>>>> version can simplify our life a bit. :-) >>>>>> >>>>>> >>>>>> >>>>>> Note that CXF, ActiveMQ and Camel works with Java 1.5. We have JRE 1.5 >>>>>> and >>>>>> JRE 1.6 profiles in jre.properties. From my point of view it is not a >>>>>> problem to stay with 1.5 but if it make sense to stay with version which >>>>>> is >>>>>> supported only if you pay Oracle for? As another note - JVM 1.5 was >>>>>> released >>>>>> in May 2004 and it is 6 year old. What do you think about that? >>>>>> >>>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Lukasz >>>>>> >>>>>> >>>>> >>>> >>> >> >
