Hi Jacques, I'm not aware of ofbiz release plans, so apologies if all this has been discussed and determined before.
Can we use trunk for demo-next rather than immediately creating a release23 branch? If possible, I would like to see release22 run for a few months before we create a release23 branch for the following reasons: - Any non-bug fixes (i.e. improvements and new features) will normally only go into trunk and will therefore not reach the users until the next release branch is created, perhaps over a year later. - If we decide to accept a non-bug fix commit into release23, we will have to merge and test in both trunk and release23. - If a serious bug is found in release22, we may find we need to fix it in three places: trunk, release23 and release22. Assuming we have a policy of releasing every year, perhaps we can schedule the next release branch creation n-months after the previous release. The community would need to converge on a suitable value of n (somewhere between 0 and 12!). I would suggest 3 as a starting point. demo-next could use trunk for the first n months after a release and then switch to the upcoming release branch when it is created. Once again, apologies if this has already been figured out. Please could someone let me know. Thanks, Dan. On Sat, 24 Dec 2022 at 11:06, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: > Hi, > > I have created OFBIZ-12729 for "Use JDK 17 in GitHub Action and BuildBot > (ie OFBiz CI) and demos" > > I expect to work on that next week. Please review and amend if necessary. > > Have a good weekend and, if you do, a merry Christmas. > > Jacques > > Le 22/12/2022 à 19:02, Jacques Le Roux a écrit : > > Hi Team, > > > > So far, we have only Michael's, Eugen's and Daniel's opinions about > releasing the 22.01.01 version under Gradle 7.6 and JDK 17 (OFBIZ-12400). > > > > To summarize, Michael is against, Eugen and Daniel are for. Daniel > suggests that we can use workarounds but need to later update OFBiz to > handle > > strong encapsulation. > > > > Michael, I was surprised by your opinion, because of > https://markmail.org/message/fq3fpxeg5yfshjwz where you said 1 year ago: > > > > <<I am also in favor of a 22.01. branch and releasing a first stable > version during the year 2022.>> > > > > And that led me to closely verify the situation. Fortunately, after > OFBIZ-12726 (integration tests), I believe we can trust using Gradle 7.6 > and JDK > > 17 by using temporary workarounds. > > > > So my question is, should we vote for releasing the 22.01.01 version > under Gradle 7.6 and JDK 17 or should we wait 22.01.02? > > > > I have decided on my side to update GH, BuildBot and demos to run under > Gradle 7.6 and JDK 17. If nobody is against of course. > > This will take some time, but I don't expect much. For that we need to > push the workarounds in all supported branches. It's not a big deal: > > > > - // jdk.serialFilter is to "Prevent possible DOS attack done using > Java deserialisation" (OFBIZ-12592) > > applicationDefaultJvmArgs = project.hasProperty('jvmArgs') > > ? jvmArgs.tokenize() > > - : > ['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=100000;maxdepth=20;maxrefs=1000;maxbytes=500000'] > > + : ['-Xms128M','-Xmx1024M', > > + > '-Djdk.serialFilter=maxarray=100000;maxdepth=20;maxrefs=1000;maxbytes=500000', > // OFBIZ-12592 and OFBIZ-12716 > > + '--add-exports=java.base/sun.util.calendar=ALL-UNNAMED', // OFBIZ-12721 > > + '--add-opens=java.base/java.util=ALL-UNNAMED' // OFBIZ-12726 > > + ] > > > > To release w/o the workarounds it is enough to remove the 2 > "ALL-UNNAMED" lines. > > > > It also would be great to freeze a 23.01 branch and use it as next demos > while replacing the 18.12 by 22.01 as stable. > > > > Looking forward for opinions... > > > > Thanks > > > > Jacques > -- Daniel Watford
