Aleks - as you are the release manager, I don't think you need to ask for a vote. ;) although happy to give this a +1 as well (binding)
The only challenge is that if you end up making changes to that branch in order to stabilize it, someone (you?) needs to make sure those PRs make it to the main dev branch. ...Or not. I suppose there can be an internal inconsistency between a release and ongoing dev without blowing up the project, although far from ideal. I think we are free to define our practice. Here are the likely dates coming up, based on team sprints I know about, *Oct 31st, Nov 14th. * So, here is my suggestion: 1) pick a date, code freeze. 2) Spend no more than a week in stabilization*** 3) Vote - takes 3 days. 4) Release. You've already started the release process by announcing that you are going to do a release. It wouldn't hurt to repeat it, but notice has been given. Let it be known that code completion is important prior to DATE. Partly completed feature PRs should be held out until after that date. ** The problem has been that if the stabilization effort reveals some partly completed code, then reverting it creates new problems and releasing with partly completed work is unstable. We may need to define "stable" in a more narrow way, i.e. some APIs calls won't work or won't work as expected documented as a "known issue". Fix it in release 1.9.x which can cherry pick for important patches. *We're better off releasing something than nothing. * --- A quarterly release immediately before our Board Report is Due would be the sensible thing. *2023: October 3rd / we should get something out now. * Then, if we can do one now, let's automate it more... and proposed: 2024: January 9th April 2nd July 9th On Sun, Oct 22, 2023 at 10:04 AM Aleksandar Vidakovic < [email protected]> wrote: > ... I'd vote for that... > > +1 > On 21/10/2023 16:04, Christofer Dutz wrote: > > Hi all, > > > > in your last board report you mentioned that the project is having > difficulties releasing, as the stream of incoming contributions makes this > difficult. > > > > Have you thought about cutting a release-branch on date that you agree > upon and then do a code/feature-freeze on that branch to stabilize things > for the release? > > > This way development can continue without interruption, and you should > still be able to release stable releases. > > > > Chris > >
