+1 Upgrading to a newer version (whether that is the actual product, or one of the underlying components - java in this case) always adds concerns/risks to the existing adopter/user.
We can only help minimising that risk with explanations on our MLs and in our documentation. We have to keep in mind that our trunks are volatile environments and the code there is not intended to be used in production environments/implementation/situations (we have our releases for that). So I advise not to go the jkd7 route as this would mean an extra workload on the community (building/testing/addressing issues/etc.). Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Mon, Feb 13, 2017 at 2:52 PM, Lucas Theisen <[email protected]> wrote: > 100% yes. > > +1 > > On Feb 13, 2017 3:59 AM, "Emmanuel Lécharny" <[email protected]> wrote: > >> >> >> Le 13/02/2017 à 09:49, Radovan Semancik a écrit : >> > Hi, >> > >> > Yes, yes, yes. The sooner the better. >> > >> > However, it would be fair to have one java7 release where the java7 >> > support is marked as deprecated. And only then switch to java8. >> > Especially for libraries and embeddable components. Such as the API. >> > The projects that are using these components may need some time to >> > adapt. I would recommend to proceed with API 1.0.0 release in java7 >> > and switch to java8 right after the release. >> >> That is an option. We can also cut 2 releases for 1.0.0 : one fore JAVA >> 7, one for JAVA 8. >> >> >> -- >> Emmanuel Lecharny >> >> Symas.com >> directory.apache.org >> >>
