2011/1/5 Jamie G. <[email protected]>: > 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.
+1; we should also ask on the smx user list, since this change will affect them too :) > > 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
