I went for Java 7 for now. So 2.3.30 will need that at least, unless someone questions the decision. (Probably we would be fine even with requiring Java 8, but, we don't need that yet, not that much.)
On Sun, Jan 12, 2020 at 8:31 PM Daniel Dekany <[email protected]> wrote: > I wouldn't increase the 1st (major) version number because of higher > required dependency versions. That just happens too often with libraries, I > think. In fact it already happened with 2.3.x for at least 2 times in the > past. As the API of FreeMarker itself didn't change in an incompatible way, > I didn't treat that as incompatible change. > > BTW, FreeMarker 2 historically doesn't use the now commonly accepted form > of semantic versioning. In modern semantic versioning, a 2nd version number > increase indicates significant new features, so with that we would be at > 2.<somewhatHighNumber>.0, not at 2.3.<highNumber>. But, in FreeMarker 2 > convention (which is communicated in our download page, and maybe elsewhere > too), a 2nd version number change indicates non-backward compatible > changes, and a 1st version number change indicates deeper redesign, as is > the case with FM 3.0.0 (after which, if it's ever released, I would switch > to modern semantic versioning). > > On Sun, Jan 12, 2020 at 8:07 PM David E Jones <[email protected]> wrote: > >> FWIW the current FreeMarker release runs fine on Java 11 from the testing >> I've done (with Moqui). Java 9 is less important in general that Java 11 >> as >> Java 9 is not a long term release as Java 8 and Java 11 are (and Java 9, >> 10 >> are already EOL). Java versioning is really confusing these days and while >> there are other sources of this info the Wikipedia article on Java >> versions >> is helpful: >> >> https://en.wikipedia.org/wiki/Java_version_history >> >> IMO moving the requirement to Java 7 is fine, versions before that are no >> longer widely supported anyway. Whether it is a 'safe' change or a good >> idea for FreeMarker depends partly on those using it, ie if anyone is >> still >> using it on Java 5 or 6. The difficulty is how would we know? Unless >> someone speaks up on the mailing list or we do some sort of survey and >> hope >> people participate it's hard to say. It seems reasonable and conservative >> to use the Extended Support dates as a guideline, which right now means >> supporting anything before Java 7 is not needed as the Java 6 extended >> support period ended in Dec 2018. >> >> For Moqui we had some discussions recently around Java versions. There was >> a push to support Java 11 (but not require it, Java 8 is the current >> requirement) as Java 11 is becoming the default on many systems and even >> without using any Java 11 APIs running on Java 11 offers a number of >> performance and memory management improvements. In certain container >> environments there are also important improvements in Java 11 for managing >> heap size relative to available memory (which is weird in containers where >> available system memory is different from memory restrictions applied to a >> given container). For Moqui the decision on Java versions is very >> different >> from FreeMarker, it's not nearly as widely used and it is a high-level >> package as opposed to a low level library commonly included in other >> packages. Even so for now Moqui is stuck on Java 8 because of a lack of >> support for Java 11 on various platforms. >> >> On a side note by semantic versioning rules (or at least my interpretation >> of them from semver.org) any non-backward compatible change requires a >> major version bump as a warning that in some cases the new version will >> not >> work as a drop-in replacement for the prior version. I don't know if the >> move to require Java 7 is significant enough to require a bump from major >> version 2 to 3, but something to consider. On the other hand it seriously >> messes up the version plans for FM3 so maybe better not to a bump from >> 2.3.29 to 3.0.0 but maybe from 2.3.29 to 2.4.0 with a release note about >> the dependency change (Java 5 to Java 7). I don't know that this is a >> must, >> semantic versioning is commonly enough used that most people understand >> the >> implications about version bumps so it is a way to communicate things, but >> with some communication/documentation on versioning policy variations on >> it >> are also used a lot. >> >> Anyway, some thoughts on the topic as it is fairly fresh on my mind from >> recent research and discussions. >> >> -David >> >> >> >> On Sun, Jan 12, 2020 at 7:55 AM Daniel Dekany <[email protected]> >> wrote: >> >> > * It's just my routine to not increase the minimum Java version, if it >> > doesn't make work significantly simpler on our side, because that can >> make >> > upgrading a problem in "legacy" systems. Using Java 8 doesn't help much >> in >> > 2.3.30, but it will once we start support Java 8 time API-s. But, >> > supporting anything before Java 7 in 2020 is totally pointless (I >> hope...), >> > and 7 helps us somewhat right now. Probably support anything before >> Java 8 >> > is totally pointless too... I'm not absolutely sure about the impact >> > though. >> > >> > * We are Java 8 compliant of course (also Java 9 compliant, as far as I >> > could test). Java 5 compliant in fact. >> > >> > * It removes some excludes, but some are to support different version of >> > other libraries. The less the better though. >> > >> > On Sun, Jan 12, 2020 at 9:49 AM Siegfried Goeschl < >> > [email protected]> wrote: >> > >> > > Good morning, >> > > >> > > so the upcoming 2.3.30 release is a sort of transition to the 2.3.31 >> > > release using JDK 8 finally? >> > > >> > > * What are the reasons not to switch to JDK 8 for 2.3.30? Please note >> > that >> > > I'm sure you have good reason to so but I want them to make more >> explicit >> > > :-) >> > > * I guess we should also migrate the existing code to be JDK 8 >> compliant? >> > > * Does this also remove the manual source file excludes when setting >> up >> > > FreeMarker in the IDE? Basically the stuff mentioned in README.md ... >> > > >> > > Thanks in advance, >> > > >> > > Siegfried Goeschl >> > > >> > > >> > > >> > > > On 11.01.2020, at 20:10, Daniel Dekany <[email protected]> >> > wrote: >> > > > >> > > > Anybody sees a problem with increasing the minimum Java version fro >> 5 >> > to >> > > 7 >> > > > in the coming release, 2.3.30? (But at least to 6. I again need to >> > access >> > > > some 6 API-s, and while I could do it with reflection, I think it's >> > > > pointless to support Java 5 at this point. And, not having proper >> > > > @Override, and diamonds, and try-with-resource is annoying.) >> > > > >> > > > Also, in 2.3.31, or something like that, we should really add Java 8 >> > > > date/time support. Starting from that, 1.8 will be the minimum >> > > requirement >> > > > anyway. Otherwise it would be way too complicated to add support for >> > > that, >> > > > because, the Java 8 classes will have to appear in the corresponding >> > new >> > > > TemplateModel sub-interfaces, not just in its implementations. >> > > > >> > > > -- >> > > > Best regards, >> > > > Daniel Dekany >> > > >> > > >> > >> > -- >> > Best regards, >> > Daniel Dekany >> > >> > > > -- > Best regards, > Daniel Dekany > -- Best regards, Daniel Dekany
