Hi Daniel, We indeed had releasing discussions in the past. It's not up to date, but we have a release plan page in wiki: https://cwiki.apache.org/confluence/display/OFBIZ/Release+Plan
Note that OFBIZ-12729 is not related to releasing. Releasing process is documented: https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz Your questions mostly relate to when freezing the next release branch. Despite that I used "23.01" for the next branch to come, nothing has been decided yet. So the community can consider your proposition. Now about the demos and the BuildBot configuration, I'd like to avoid switching and renaming multiple times. Both are respectively documented at https://github.com/apache/ofbiz-tools/tree/master/demo-backup https://github.com/apache/ofbiz-tools/blob/master/documentation/BuildBot/BuildBot.md All is open to discussion and amendement :) Jacques Le 24/12/2022 à 18:11, Daniel Watford a écrit :
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 aboutreleasing the 22.01.01 version under Gradle 7.6 and JDK 17 (OFBIZ-12400).To summarize, Michael is against, Eugen and Daniel are for. Danielsuggests that we can use workarounds but need to later update OFBiz to handlestrong encapsulation. Michael, I was surprised by your opinion, because ofhttps://markmail.org/message/fq3fpxeg5yfshjwz where you said 1 year ago:<<I am also in favor of a 22.01. branch and releasing a first stableversion during the year 2022.>>And that led me to closely verify the situation. Fortunately, afterOFBIZ-12726 (integration tests), I believe we can trust using Gradle 7.6 and JDK17 by using temporary workarounds. So my question is, should we vote for releasing the 22.01.01 versionunder 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 underGradle 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 topush the workarounds in all supported branches. It's not a big deal:- // jdk.serialFilter is to "Prevent possible DOS attack done usingJava 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 demoswhile replacing the 18.12 by 22.01 as stable.Looking forward for opinions... Thanks Jacques
