[Bf-committers] Release cycle idea

Nathan Letwory nathan.letwory at gmail.com
Mon Aug 12 18:09:44 CEST 2019

Some good points. We have had a dev coordination meeting
since. Dalai already sent the notes with the updated release
cycle info, but to quickly sum up:

* 2.81 release in November
* Use project milestones instead of custom field
* cut-off date for major work early enough
* no releases too close to big events

I'll be updating my wiki page on release cycle in a bit
to reflect what we discussed.


On Mon, Aug 12, 2019, 12:05 Brecht Van Lommel <brechtvanlommel at gmail.com>

> This is missing a cut-off date for major new features or risky
> changes, which should more than one month before the release date.
> There is no way we can for example merge Mantaflow at the end of
> September and then release a month later. This is important
> information for developers working on such projects.
> We should stop calling tests builds release candidates. That
> terminology is confusing, and should be reserved for a build that
> might become the actual release, not one where we know there will be
> more bug fixes. Making RC builds is not ideal in general, the only
> good reason to do that is to detect issues that are not in the
> buildbot. If we can get the buildbot to make our final releases we can
> just have daily builds of the stable branch for testing.
> We should target releases to explicitly _not_ be near events like
> Blender Conference or SIGGRAPH. Otherwise the people handling the
> release will often be busy or travelling.
> I'm a proponent of having a separate master and stable branch. I think
> it's important to not block all developers whenever we get towards a
> release, and instead have a smoother system where all developers can
> work at their own pace. However this does require good management and
> discipline, so that developers who add new features take
> responsibility to fix issues in the stable branch, rather than moving
> on to the next thing.
> A downside is testing, it's likely that the majority of buildbot users
> will continue to test master with all the new features rather than the
> stable branch. I think it will be ok in practice, but it's still
> something to be aware of. The extra work of merging branches and the
> fact that some developers are not comfortable with git merging can
> also be a problem. It wasn't a huge issue when we did something
> similar with blender 2.7 and 2.8, but still resolving merge conflicts
> was generally done by a handful of few core developers.
> An advantage of multiple branches is that we can increase the testing
> time for major changes. Even with a 2 month release cycle, a feature
> can be tested for 3 months before it ends up in a release. Or 4 months
> in a 3 month release cycle.
> Why add a new task field rather than using Phabricator milestones?
> Task fields get added to all projects, some of which are not tied to
> Blender releases. If it's a field it should at least have a None
> value, but I'm not sure why it should be a field.
> I think it's fine to have a list of bugs or other tasks that must be
> fixed before the next release. If something is really broken or we
> can't release without it, then we must have an overview of that.
> However I believe attaching features ahead of time to specific
> releases is actively bad. It leads to rushed implementations and bad
> priorities. It is notoriously hard to estimate how long development of
> a feature takes. Trying to organize development around a planning that
> does not reflect reality is more harmful than helpful. Instead we
> should prioritize tasks by importance, and when they are finished they
> go into the next suitable release, whatever it is, early or late. I
> think we have to really resist trying to plan what will be in each
> release. It does not scale for a complex open source project like
> Blender with a lot of people involved with their own unpredictable
> schedules.
> If we were to go ahead with this, how would this be done exactly? We
> have thousands of tasks, would they all default to "Future" or "None"?
> Would bug triagers be expected to estimate when a bug will be fixed
> by, and developers estimate when they will complete each task? Who
> would be responsible for ensuring this information stays up to date?
> Would these numbers be considered like a promise by users, which we
> then keep breaking regularly?
> Further, I think the idea of major releases needs to be abandoned and
> no tasks should be targeted for them. We should be able to to do major
> improvements in regular releases and not delay them until some major
> release. Major releases like 2.5 and 2.8 have been quite bad for
> external contributors and a nightmare to organize for us, I do not
> want a repeat of this.
>  A blender:released-in field is useful information. But it needs to
> solve a problem to be worth the bookkeeping overhead, and it's not
> clear to me what that problem is. Auto-generating bugfix lists from
> this can be convenient, but it also requires discipline to tag
> everything correctly and retitle bug reports, whereas "git log" is a
> list that is automatically complete. Triaging bugs and keeping tasks
> on developer.blender.org up to date is a lot of work already. We have
> to be careful when adding even more things to maintain there.
> On Mon, Aug 12, 2019 at 12:35 AM Nathan 'jesterKing' Letwory
> <nathan at blender.org> wrote:
> >
> > Hi,
> >
> > I've typed my thoughts on the release cycle over at
> >
> > https://wiki.blender.org/wiki/User:JesterKing/ReleaseCycleNotes
> >
> > (also contains a pretty picture) but here in short the high-lights:
> >
> > * if we go for a release just with Blender Conference (24th of October)
> > * we could do a three week stabilizing:
> >   RC dates could be
> >   - 30th September (cut-off date - 2.81 stabilizing branch created, RC1)
> >   - 7th (RC2), 14th (RC3), 21th (RC4) October
> >   - After RC4 there should be no show-stoppers, meaning the RC4
> >     could be rereleased as official 2.81 (proper tagging in repos)
> > * blender:release-target custom field for Maniphests in use during
> >    week 33
> > * weeks 33-39 (2019.08.12-2019.09.29) time to work on new stuff
> >    and improving existing
> >
> > After 2.81 (Blender Conference) we could settle into 3-month cycle
> > that would allow for targetting releases around SIGGRAPH and
> > Blender Conference.
> >
> > Nothing has been set in stone regarding dates, but this week I want
> > to implement at least the basic custom field for maniphests. There
> > should be no changes to how we all type code in the coming weeks.
> >
> > Have a good week!
> >
> > /Nathan
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list