BTW, if we do agree to drop Java 6, do we create a 1.6 maintenance branch or just leave the tag, and if need be cut a bug fix release then?
John On Fri, Mar 25, 2016 at 8:06 AM John D. Ament <johndam...@apache.org> wrote: > To me, dropping support for Java 6 doesn't mean rewriting the code base to > only be compliant with Java 7 and up. > > It does allow for some new stuff in our codebase, if we want to go back > and clean it up: > > - try-with-resources > - automatic type inference on generics. > > But those are just clean ups, no real new functionality. > > John > > > On Fri, Mar 25, 2016 at 4:24 AM Thomas Andraschko < > andraschko.tho...@gmail.com> wrote: > >> basically +1 >> Most of our customers are using 1.7 since this year. >> >> I just wonder whats the benefit for us? >> I think there are no language features which would improve our code base. >> >> 2016-03-25 3:25 GMT+01:00 John D. Ament <johndam...@apache.org>: >> >> > Hey guys, >> > >> > I've brought this topic up before without much positive response. I >> figure >> > I'll bring it up again. >> > >> > I'd like to propose that DeltaSpike 1.6 be the last minor release to >> > support Java 1.6. I suspect that most users are already using Java 7 or >> > higher. None of our builds in CI (builds.apache.org) currently run on >> 1.6 >> > either, so while we can say from a syntax standpoint we're 1.6 compliant >> > I'm not sure we can say from a JDK Library standpoint we don't rely on >> > anything from Java 7. >> > >> > We're one of the few projects that probably still supports Java 6 as a >> > mainline development, so I was hoping we could just cut 1.6 as 1.6 >> > compliant, if we need to cut patch releases of 1.6 to apply patches, but >> > with DeltaSpike 1.7 and on, focus on Java 7 and up. >> > >> > John >> > >> >
