Le 07/01/2025 à 17:09, gil.portenseigne a écrit :
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.
It's clear there https://wiki.ubuntu.com/DevelopmentCodeNames and fits to
"Bratislava's" proposition :)
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 !
Quite clear, sounds like a plan
Thanks Gil
Gil
Thanks !
On 07/01/25 11:32, Jacques Le Roux wrote:
Hi,
After writinghttps://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
