[...] > > Do you really mean "releasing a new release" or "freezing the trunk while > creating the next release branch"? (of course the trunk is never freezed) >
Nope, just like you did, we will release soon 24.09.01 (first release of the new stable), and you offer to wait to finish minilang migration before creating a new branch from trunk (freezing). > > > 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. > > OK, you speak about freezing, right? Once freezed, apart rare exceptions, > there is nothing to think about, only bug fixes are accepted. yes "creating the next" is about freezing. > > > > 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. > > That sounds like fun and a good idea. Ubuntu is using names like that, not > sure at which time point. > > > > Before that, for demo, next is trunk 😄? > > Why not after all as long as we have not given a name to the new freezed > branch (ie freezed it) Yes, but we can create a git branch named next or freeze or whatever, that only accept bug fixes, then push the reference to a named one, once the new name has been decided. I hope i am more clear now, sorry for that ! > > > > Gil > > Thanks ! > > > > 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 > > >
