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
