Hi Deepak,depending on the model we choose, this could be a consequence, yes. This was one of the reasons why I raised this topic.
I see the advantage that we'll have to be more focused on stability and make good decisions what will go into a release. The downside is that we'll have the release overhead at least twice a year and we might have to maintain trunk plus 2 release branches (current release and next release with Java pre-release).
Regards, Michael Am 31.01.18 um 06:07 schrieb Deepak Dixit:
In this case what about our release polices? Are we going to update release as well in every 6 month? Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co On Wed, Jan 31, 2018 at 12:52 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote:This indeed lets not much choices Jacques Le 30/01/2018 à 18:35, Taher Alkhateeb a écrit :I see. Hmm, then I'm not sure, but perhaps we have no choice but to go with the short term releases then. On Tue, Jan 30, 2018 at 8:32 PM, Michael Brohl <michael.br...@ecomify.de> wrote:The problem with LTS is that it is not free. If we stick to LTS, we won't support the users which use the public versions. To get security updates, these users have to change their version every half year. It's difficult to say if you will have compatibility problems beetween those public versions but it is possible. Regards, Michael Am 30.01.18 um 18:12 schrieb Taher Alkhateeb: Sure but If we choose to go with 9, then we _must_ keep jumping every6 months or so. You either stick with an LTS or you don't, and as per my understanding 9 and 10 are not LTS. Read the article for more information. On Tue, Jan 30, 2018 at 8:01 PM, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote:That sounds wise to me, maybe we can try Java 9 though, to not get too much things to do later? Jacques Le 30/01/2018 à 17:49, Taher Alkhateeb a écrit :If I understood the documentation correctly, we have to choose between two different packages: - Stable release (long term support, less features) - Feature release (short term support, more features) Of the two, I think the stable LTS seems to be more compatible with our own release cycle. Also we don't usually go crazy with feature adoption and we prefer to take things slow. So we can perhaps stick with JDK 8 for as long as we need and maybe then jump to 11 when we are ready. On Tue, Jan 30, 2018 at 1:30 PM, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote:Hi, I was wondering about that too when I read this thread on Tweeter https://twitter.com/holgerbrands/status/957572736129339392 But it seems OK finally Jacques Le 30/01/2018 à 10:27, Jacopo Cappellato a écrit :Thank you Michael for starting this thread. When discussing this, we will also have to consider that OFBiz currently depends on several other Open Source products that will have to be compatible with the platform we will choose (however, considering that backward compatibility is maintained in new Java releases this is not going to be a major concern). Jacopo On Mon, Jan 29, 2018 at 5:21 PM, Michael Brohl <michael.br...@ecomify.de> wrote: Hi devs,this is just an initial information and dicussion starter to make everyone aware of this: the Oracle Java release model is changing from a feature based to a time based model [1]. One major drawback is that there will be no more public patch releases for older versions once a new release is published, if I understand correctly. We'll have to discuss if this affects the project in terms of support for the latest public Java releases. If we want to stay up-to-date according to the public releases, we'll have to establish a process to early check the new features and changes of a coming release and maybe release more often. We might even have to support the latest Java release along with the current LTS release to cover both users with and without commercial support? I'm not sure. What do you think? Best regards, Michael [1] https://www.azul.com/java-stable-secure-free-choose-two-three/
smime.p7s
Description: S/MIME Cryptographic Signature
