What you propose sounds more like a flow for features, and not so much bug fixes. From what I can tell this is what pretty much already the current release flow is sans LTS. And based on the original proposal by @Ton our current release cycle gives about a year for features to mature in regular releases.
I’m not sure if dropping the regular releases of your Stable (our current releases) benefits the user. Sure, those who know and are comfortable with it can download from the nightly builds, but I believe we still see big download counts for the actual releases - my impression is that many users still prefer official releases.
It isn’t like we are about to take a year-old release and make that an LTS. We are about to crown our 2.83 as an LTS and it has features that have been very recently added and will have bug fixes added the same day. And then a year from now we’ll do similar from a snapshot of the branch at that time. So an LTS is just a regular release that we then start treating specially. The day the LTS is released it is no more stable than our regular build.
My musing were about treating these branches as streams of differing stability. At any moment an Experimental branch download could contain changes from that same day, while a user could download Stable knowing that any features or bug fixes have been at least tested for a reasonable time. And users downloading an LTS would know that all features have been tested for at least a couple of months.
Right, it was more that I didn’t see what you were getting at. How you put it made it much clearer to me.
An approach like this would mean quite a big change in how we do our current patches and the sheparding of these into maturity. Interesting, but I’d like to hear from other active devs what they think of such an approach - @dfelinto, @brecht, @mont29, @sergey, @ideasman42 . I’m guessing though that this would be a too big change from our current practices.
For Ubuntu LTS releases, I don’t think the LTS on release day is particularly more stable than other releases. Users that value stability will typically wait a while before upgrading. This is why I brought up delaying the marking of a release as LTS a bit. But I don’t think that is actually the standard way to do it.
Part of the reason for an LTS is for an animation studio to be able to start and finish a project in the same version. It’s not necessarily about having the least amount of bugs (though that option exists by waiting to upgrade), but also preserving backwards compatibility and not breaking the project files.
For example Unity still has 2017 LTS releases, which probably are not significantly more stable than 2018 LTS by now. Rather some games were developed with that version and the game developers in turn just want to release minor bugfixes of their games, not rewrite a lot.
I also think it’s important to understand that we have some flexibility in how much time we spend on this. There are certain types of bugfixes that we’d always want to backport (e.g. security or data loss issues), but for the most part “important bugfixes” is a flexible definition. It’s definitely not the intent to backport every bugfix, and likely in the second year the amount of backported fixes will be significantly smaller than the first.
If there is a big demand to backport more bugfixes (or even other types of backwards compatible improvements), we can find funding for that or get interested parties to contribute. We’re not making a promise here that if a bug for an LTS version is reported to the tracker, that we will actually investigate it. It should meet our standard for “important bugfix”.
@brecht, well money decides.
IMO going to the 2.8 series was intended to rewrite Blender’s core, so that it would be a modern program. To take the lessons learned from the past and get a good coding and data structure, so future releases could use more uniform structured and extendable data. Blender would get future ready proof in 2.8x. Shouldnt that mean less need for ‘freezed’ versioning systems like LTS. The changes now might seam huge as compared to the passt, but future changes are likely smaller, and be more of the type extensions than of the type core design change.
The following suggestion of version numbering is inspired by what SideFx are doing with Houdini
A new release every 6 months, it goes like this :
starting with the 3.0 after that we’ll have 3.5 and then 4.0 then 4.5 etc
Bigger feature like mantaflow, particles nodes, API breaks etc will come with version number like 3.0 - 4.0 - 5.0 - 6.0 etc.
Version numbers like 3.5 - 4.5 - 5.5 will be a more stable release of the previous one, no api changes nor big features, 3.5 will be a more stable version of 3.0 but with new littles features and more bug fixes etc, and those will be the LTS.
LTS numbering can be like :
3.5.1xx - 3.5.2xx - 3.5.3xx
or
3.5a - 3.5b - 3.5c
or
3.5r1 - 3.5r2 3.5r3
Dev will have to work on 3.5 and 4.0 in the same time, let’s say for exampe that dev now work on 3.5 but one of the dev is working on something that will break things, he will be commiting code in the 4.0 branch.
as an example, If we remplace 2.90 with 3.0 here’s how it goes for everything nodes project
summer 2020 blender 3.0 is released it introduce Particles nodes :
dev will now work on bug fixes, more nodes, and polishing overall for 3.5
January 2021 3.5 is released, dev now will work on geometry nodes and fixe bugs for 4.0
summer 2021 4.0 is released with geometry nodes, dev now will fixe bugs and do more polishing for 4.5
That would definitely be helpful. I currently rely on a post-2.83 bugfix, but don’t wan’t to use 2.90 yet. I’m looking to build Blender myself instead now.
I will also require that commit to be the minimum version requirement for users of my addon, and so a means for them to download a post-2.83-yet-not-2.90-build would be nice.
Monthly bugfix releases for 2.83 would be perfect in that context too.