On Thu, Jun 27, 2013 at 4:06 AM, Hugo Trippaers <h...@trippaers.nl> wrote:
> Hey everyone, > > Back in February 2013 Oracle announced the end of public support for java > 1.6 already. Today we are still using java 1.6 as our supported platform. > I've been looking at the next generation of linux distributions (well > mainly at Fedora 18, which will probably become RHEL 7) and those platforms > ship with java 1.7 by default. > > Next to that several core components are also upgraded with affect our > installation. RHEL 7 will most likely use tomcat 7 as the default tomcat > platform for example. > > If we want to start shipping for those platform we will have to start > testing with these versions of the software as well. I'm already working on > some things that need to be done, like replacing the existing init scripts > with systemd versions and adapting the spec file for the new OS, but there > is more to it than that. > > I'm wondering what we need to do on the source side of things. My proposal > would be to at least configure maven to set the source version to 1.7. +1 Let's do it! > This requires developers to use the java 7 versions of the jdk. We can > leave the target to 1.6 for the time being to ensure that the packages > could still run on a 1.6 jdk. > > However at a certain point we should start to advice people to run > CloudStack on java 1.7 as there are no more public security updates to java > 1.6. > > So summarized proposal, make 4.2 the last version to support 1.6 and > switch maven source version to 1.7 after we cut the release branch for 4.2. > The new reference platform for the next release would be jdk 1.7 and > tomcat7 (meaning packaging will be tested on those platforms). > +1 > So what do you all think of this? If we are ok to do this i would like to > start with this right after the release branch cut. This constitutes a > major architecture change so i would want this to be in as early as > possible in the release cycle. > We should do it, we don't have much choice I guess if 1.6 will go away, it makes sense to adapt and build on the latest. And as a side note, are there any other version updates we would like to > see in that release. We depend on several ancient libraries if i'm looking > through the pom files. Maybe we should consider upgrading a few > dependencies to more recent versions? > Few of the dependencies have issues, so upgrading few of them can actually break stuff, for example in cloudstack-awsapi. But, yes we should upgrade the rest of the dependencies, have the latest/stable ones. Cheers.
