Sounds good to me!!
I wanted to propose a change in process regarding the stabilization of code
releases.
Instead of restricting commits directly to the trunk, I suggest creating a
branch named "24.04" or "24.05" (depending on the release version)
specifically for stabilization purposes. This branch will serve as a
dedicated space for stabilizing the code without impacting ongoing work in
the trunk.
By implementing this approach, we can focus on stabilizing the release
branch independently while allowing continuous development to proceed on
the trunk. The only additional overhead will be the need to backport bug
fixes from the release branch to the trunk or vice versa.
I believe this strategy will help us maintain a more organized and
efficient development workflow, ensuring that our releases are stable and
reliable without disrupting ongoing development efforts.
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
On Sun, Apr 21, 2024 at 7:20 PM Michael Brohl
wrote:
> Hi everyone,
>
> we agreed to work towards a stabilizing trunk to be able to create a
> 24.x release branch, which means we have to thoroughly decide which
> changes should go into trunk. There are currently lots of changes going
> into trunk with PR's created and rapidly be merged into the codebase.
> This causes potential for errors being introduced in trunk, potentially
> leading to delay the creation of the next release branch even more.
>
> In my opinion, this is contraproductive to the goal of creating a stable
> release branch 24.x in due time.
>
> I propose to make a decision to have a code freeze for new features and
> improvements and focus on bug fixes until we have created a 24.x branch.
>
> I also propose that we start organizing a roadmap to give the community
> some guidelines where to focus and which main features can be expected
> in the next release branches. It might also give developers some goals
> to provide the features according to planned releases and maybe work
> together to reach those project goals.
>
> For example, there are some initiatives for Tomcat migration,
> introducing REST functionality in the framework and others which we can
> assign to future release branches. Maybe we can have a plan for a 25.x
> release branch which introduces those features.
>
> I do not intend to make this an unflexible roadmap, means there can
> always be more planned/unplanned features be added to the roadmap and be
> discussed. We should have some deadlines for new features though, just
> to be able to create the next feature branch in the planned time periods.
>
> What do you think?
>
> Best regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
>
