cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <h...@trippaers.nl>
Subject [DISCUSS] Java 7, tomcat 7 and further upgrades
Date Wed, 26 Jun 2013 22:36:31 GMT
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. 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). 

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.

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?

Cheers,

Hugo



Mime
View raw message