Hi everyone, Blenders relese cycle is divided into five different phaes, Bcon1 to Bcon5. Over the past few months I coordinated the release process for 3.1, 3.2 and recently 3.3.
Doing that I identified a few challenges and uncertainties which I like to get feedback on from developers to possibly improve the current system.
Bcon1
Bcon1 is the first phase, in which bigger features and branches are commited to master. The first few weeks of this phase overlap with Bcon3-5 and many developers will focus on bug fixing in those first weeks.
The scheduled date to move from Bcon1 to Bcon2 has been postponed almost every release this year for various reasons. The main reason is unfinished features and developers requested more time to finish them. I am okay with making an exception once in a while, but since this happened for 3.1, 3.2 and 3.3 it’s rather becoming a rule. Of course it’s possible to stick to the original schedule, moving everything that is not ready for merge by day X automatically to the second next release. But this leads to the situation described below during Bcon2.
What can be done to improve the Bcon1 situation? Is the overlapping release schedule still working?
Bcon2
Bcon2 is described as phase to
improve, optimize and fix bugs in new and existing features. Only smaller and less risky changes, including small features, should be made in this phase.
This isn’t very clear to me, what exactly is a “smaller and less risky change, including small features”?
There is some temptation to commit work during Bcon2, even though (in my oppinion) it should have gone in during Bcon1 already. Therefore I’d welcome a better definition of what is allowed in Bcon2 and what is not. What metrics can be used to distinguish between a large and a small feature? Changed lines of code? Complexity? Is it an addition to an existing feature or is it something completely new? Ideas are welcome.
Other phases
The two points mentioned above may not be the only things that could use some clarifications. If you have further points or feedback, you’re welcome to bring this up.
For the BCon1 we need to get more strict in both timeframe and on planning.
Big features for an upcoming release needs to be planned for merge in the early days of BCon1. Sure there will be always delays, but that is why BCon1 has a non-zero duration in time. This applies to our own projects, and external contributors.
If a project is not ready for inclusion, delay it for the next release. There is nothing wrong, or bad about it. Better not to stress developers of the project, and release team.
Is the overlapping release schedule still working?
With some caveats you’ve mentioned, yes, I think it is working. Not having the deep freeze in master branch helps a lot with the external contributors.
If we are to re-consider the overlapping schedule I think we first better try to solve problems of it, than to cancel it all together.
This isn’t very clear to me, what exactly is a “smaller and less risky change, including small features ”?
There will always be some grey area to it. Think more proper metric is something which involves design. If a project has big design changes then it is definitely needs to happen at BCon1. If something is a new feature but lives within the existing design then it can happen during BCon2.
A random example: asset browser should be committed at BCon1, but operator in clip editor can be added during BCon2.
Before the current release schedule there were already frequent delays, often weeks or months instead of days. I think with the bigger and more distributed development team now, with freedom for modules that make their own planning, that would not have scaled.
Regardless if there is overlap or how long the release schedule is, we will always be coming up to a deadline and needing to make the decision to squeeze something in or not. To avoid delays in the schedule, I don’t see any other solution than being strict.
I think developers (myself included) need to get better at pacing themselves. One nice thing we had previously is that there was a clear period when the few full-time developers would focus on bug fixing and help each other. It felt like we had stability better under control then, and there was a more clear break when we could move from bug fixing to new features. In some ways that was due the ability to delay as needed.
I don’t think it’s possible anymore for the entire development team to work in lockstep like that. But on the individual or module level, I think we should be handling high priority bugs and other essential tasks for the next release before moving to tasks beyond that. Now sometimes developers are rushing to get a feature ready for bcon1 with the idea to catch up with other tasks after that. Instead, do those other tasks first so that the next bcon1 you have more weeks to focus on the new feature, and maybe even merge it well before the bcon1 deadline.
There maybe useful tweaks to make to the schedule. The current one is not necessarily optimal but there are always trade-offs.
For example we could do 3 releases per year, and add two weeks to bcon2 and two weeks to bcon3 with the aim of getting more stable and polished features. Developers may be more likely to be done by the time bcon1 starts then. However other developers and contributors have to wait up to 2 months to get their features merged, and now we may be rushing to merge even more features in bcon1 that have piled up in those 2 months.
Or you could have 2 releases per year, or 3 where one is 6 months and the others 2 months. There can be some benefit in not having to think much about deadlines in the first few months of a 6 month cycle. A module can also decide themselves to work on that kind of pace and only aim for new features every other release.
Take that 6-month one, align it so that it releases in late January. That means it can incorporate all requirements of the VFX Reference platform, since they only finalize between September and November. That first release of the year becomes our LTS, which is also VFX compliant, and gets a name like “Blender 2023”. Immediately after release we bump the deps on master and play with the new stuff until that fall. It also means we’d be working on that release during the Conference, which is a fun time to show off new features.
To be clear I’m not even recommending we use the alternative schedules I mentioned. Hard to tell if it would be better or worse as a whole. But pressure/overhead from the frequency of releases is the most common complaint about the current schedule.
For the VFX platform, the purpose is for all releases in a year to match it. If we bump libraries for intermediate releases those will not be matching either the current or next year.
Greetings,
since I asked for couple of days of delay in previous 2 releases it’s best to outline how it happened. I speak only on behalf of myself and maybe a portion of the community folks, I have no idea what delaying the next release cycle means for the core team.
Community is scattered. We know each other briefly from chats. We rely on each other for code review, testing, artistic feedback. But the difference is - no one is in command. No one reports to anyone. It’s all free time passion. Sometimes schedules don’t align, someone is overburdened at work, the other one is on vacation, the third one is sick. One thing is certain - it sucks to invest some time in a feature and then miss the deadline for only a couple of days, when all that is needed is a thumbs up from whoever is cooperating. We are aware of the dates, but sometimes it does not work out. I can only say we can try to do better. After all, it was just asking for delay, not demanding it.
Like I said, I have no idea what delaying bcon2 means for the team. But since community people are usually making only small improvements, I would argue even for making bcon2 less strict and more accepting. I like the 4 releases per year - it provides enough incentive and excitement to work on stuff. To miss the date in 2 releases per year cycle, that is almost a guarantee, that we’re letting the patches die of without this timely incentive for improvements.
As shown in blender today poll (NODE GROUP ASSETS - Blender.Today LIVE #210 - YouTube) community is supportive of 3 releases per year. I think this + a little less restrictive bcon2 it could work nicely. Less overhead and still flexible.
