Hi Jacques, Thinking out loud :
The idea could be to wonder when first releasing a new release, is there any pending or desired effort to be put into the next release to decide a possible roadmap to tackle before creating the next release. After that covered, creating next git branch, for stabilization before giving it a name. In Bratislava we discussed a bit about the naming process, joking about some fun names... when stabilization period is over we could decide for the name to avoid "late name" like release22 that is released in 2024. Before that, for demo, next is trunk 😄? Gil On 07/01/25 11:32, Jacques Le Roux wrote: > Hi, > > After writing > https://lists.apache.org/thread/wsx97qgx9g6x97fgssjrg4rmj982825d, with a > partial copy below, comes the necessary complement. > > <<The issue I perceived and was not clear in my mind, is we have the > informal concept of stable, next and trunk. That's initially a demo concept > but it has reality roots. > When we will release 24.09.01, so officially defines 24.09 as replacing > 18.12 as stable, it makes sense to create a new "next". > After soon 7 years of efforts, It would be better if OFBiz "next" branch > eventually has replaced all Minilang by Groovy. As we did long ago for > Beanshell.* > > There is also an implication for demo: what will be "next"? > > As the "next" concept is informal, it's not a big deal. We could have no > next for a moment, or either use 24.09 as next (much easier). > As I'm more than often the demo maintainer I'd quite prefer to use 24.09 > as next, with an information about it of course. > > Other ideas? >> > > So I propose to not simultaneously create the new "next" branch when > releasing 24.09.01. > We have no obligation to then create the new "next" branch. > This to let enough time to complete the Minilang by Groovy task in trunk. > As soon as it will be done we can create the new "next" branch and update all > the CI and demo parts. > > What do you think? > > Jacques >
