Hi Michael,

How (by which mean) do you envision to "actively inform users about our 
roadmap", blog, wiki or embedded documentation?

It seems the blog is not reaching all our users (needs attention). Maybe an 
initial statement could be used there though.

The wiki is slowly deprecating in favour of the embedded documentation. So I 
guess we will use the embedded documentation for lasting information, right?

BTW All, I want to close OFBIZ-9226 "Check that OFBiz runs and compile with Oracle JDK 9 (Java 9)" as unresolved and create a new similar issue for Java 11, what do you think?

Jacques


Le 28/07/2018 à 13:29, Michael Brohl a écrit :
Hi Mathieu,

my goal is to actively inform users about our roadmap and provide information on how the project will deal with the new Java release model. Users testing OFBiz for their needs in a professional environment also check if a project has answers to these questions so I am wrapping my mind around it.

This is just to make clear that I am not eager to switch to newer Java versions 
just for the sake of it.


Am 28.07.18 um 12:54 schrieb Mathieu Lirzin:
I wonder if we should base the OFBiz 17.12 release on Java 8 or Java
11. We have no fixed release date yet so we might have time to do it.

Another way would be to make a new branch which will support Java 11.

What do people think?
I think OFBiz should be conservative in its choices.

I agree!

Given the fact Java 11 is not release yet or is about to be released,

Java 11 will be released as GA in Sept 18. At the same time, non-subscribed 
users will get no updates for Java 8 any more.

OFBiz should keep compatibity with the previous LTS release meaning java 8.  Of 
course

Yes, you are right. If you focus on subscribed users, they will get Java 8 
support until September 2023 (2026 for extended subscription).
So following my thoughts to assume that users will subscribe, we can stay with 
Java 8 for a while.

On the other hand, if we test Java 11 and find that we will have few issues we can easily handle, it could be a good idea to make the switch with release 17.12.

I am open to both (or other) models and would like to hear more opinions about 
that.

This does not mean that OFBiz should not be tested with more recent Java
releases too.

Having an extra branch has a maintenance burden that should be balanced
with the benefits it provides.  What benefits do you see in having a
Java 11 branch?

This is just an alternative to the Java 11 update of the next branch. I do not 
favor this because of the extra maintenance burden you mentioned.

In conclusion, we can stick to Java 8, informing our users that they have to 
subscribe for further updates.

If we do this, we should think about a roadmap/ process to change to Java 11 in the future. This could be, for example, set up during the release branch 21.x or 22.x to give us enough time.

We should also, in my opinion, check/test for Java 11 and following versions compatibility in the next months to be able to inform users about compatibilities/incompatibilities with this version. Maybe we can provide some compatibility matrix or else.

Thanks for your thoughts,
Michael









Reply via email to