Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Stephen Davidson]

Good afternoon.




Regards,
Steve

On 5/6/24 04:07, Jacques Le Roux wrote:

Maybe I am missing something, but why can't WIP be executed finished & stabilized on the Release Branch and then merged to Trunk?

Hi,



We can't wait and complicate the situation before that.

Jacques

Le 06/05/2024 à 10:36, gil.portenseigne a écrit :

We should 1st clearly identify WIPs in trunk and at which stage they are each.

Hi,

I feel like Michael, when there are 'in progress' work in trunk, when we
create a release branch for stabilisation, the remaining work of such
task will only be in trunk (since those are improvements).

But delaying release is not good when we look at the name of our last
release that show the 2018 year.

The concession we could agree on should be to identify such tasks to let
user know the partial improvements contained in the release.

i.e. creating release branch + roadmap :)

WDYT ?

Gil
On 22/04/24 04:12, Jacques Le Roux wrote:

Hi Guys,









Jacques

Le 22/04/2024 à 09:37, Daniel Watford a écrit :

Without getting into details, I tend to disagree with your propositions. I can't see why we would change our very simple way of doing. When we freeze a branch, the activity can continue on trunk. It does not interfere with the new release branch. The only variable is the period we allow before releasing the branch. Then, that depends on the breaking changes (or not) we recently made. Why should we change? I fear it will rather introduce complications. Please keep it simple. TIA for your explanations on simple reasons to change : what is wrong with our current way of doing?

Hi Michael,

I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.


year, but alas trunk marches on and I think it will be difficult to
mandate a period of release-related-only changes in trunk.


to take place simultaneously on trunk and the 24.x release branch.


generally accessible. Without more frequent releases we will have the
temptation to port major functionality into already existing release
branches which might take a large amount of effort and could introduce
instability between minor releases. I hope my inference reflects your
intended proposal! :)

Yes to a roadmap.

Thanks,

Dan.


On Sun, 21 Apr 2024 at 14:50, Michael Brohl <michael.br...@ecomify.de>
wrote:

I too was hoping that we could freeze trunk before creating a 24.x release branch as I was concerned about the about of duplicate work (backporting) that might need to be done if we took a 24.x release branch earlier in the Instead I think, as Deepak mentioned, we should take a new 24.x branch to use for stabilisation - with tags denoting the actual releases along that branch. It feels that the large projects - such as groovy-scripts migration - have completed which should reduce the amount of rework that would have >From your comments I infer that you may be suggesting yearly releases. I think this is a good idea as it will allow the introduction of major new functionalities in trunk without needing to wait years for them to become

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

into trunk with PR's created and rapidly be merged into the codebase.

leading to delay the creation of the next release branch even more.


release branch 24.x in due time.




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,

release branch which introduces those features.

I do not intend to make this an unflexible roadmap, means there can


What do you think?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

changes should go into trunk. There are currently lots of changes going This causes potential for errors being introduced in trunk, potentially In my opinion, this is contraproductive to the goal of creating a stable 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 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 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.

OpenPGP_signature.asc
Description: OpenPGP digital signature