... agree...
On 22/10/2023 19:44, James Dailey wrote:
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
