Hi,
On 06/27/2013 12:36 AM, Hugo Trippaers 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.
Don't forget the Deb packaging ;) I'll take care of 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.
In favour of setting source to 1.7, but target 1.6 and that should at
least stay so until 4.5 I think?
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.
True, but that doesn't change the fact that some people might need to
run 1.6 for some other reason we can't come up with right now.
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).
Doesn't tomcat7 imply that target is also 1.6?
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?
That should be a ongoing process, since dependencies indeed get newer
versions and that could bit if we don't keep up.
Wido
Cheers,
Hugo
