Hi Michael, I'm broadly in favour of your proposal, but perhaps with a slightly different 'shape' to the approach.
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 year, but alas trunk marches on and I think it will be difficult to mandate a period of release-related-only changes in trunk. 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 to take place simultaneously on trunk and the 24.x release branch. >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 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: > 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 > > > -- Daniel Watford
