Hi Gil,
Le 07/01/2025 à 14:35, gil.portenseigne a écrit :
Hi Jacques,
Thinking out loud :
The idea could be to wonder when first releasing a new release,
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)
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.
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)
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
