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
wrote:
> I wouldn't increase the 1st (major) vers
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 di
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 whil
* 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 a
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 migra
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 d
