Blender LTS and 3.0

After evaluating the massive support for Blender 2.80 – and with the 2.8x release cycles running as planned – here is a proposal for the long term Blender release organization.

Blender LTS

The first proposal is to do one Long Term Support (LTS) release every year. This release would be supported for two years with important bug fixes and updates for new hardware, while strictly maintaining compatibility.

A good reason to do an LTS now is the focus on fixes and patches of the past months. The next release (2.83) although big, will be relatively less experimental, thus a good candidate to keep supporting for a while.

LTS versions also will help to ensure that a project that started with an LTS version can be completed with the same version in a reasonable amount of time. Nice for studios with large projects, but also for add-on maintenance.

A surprising amount of requests for LTS ‘agreements’ came from corporations who have more strict installation procedures internally – for various reasons they do not want individual employees to download our releases. An official LTS with controlled install would fit their procedures much better. We will further investigate this topic in the coming period.

For our daily testers and early adopters this is also good news. It means we will be able to more easily add experimental and new features in regular releases. Expect a continuous stream of new features and improvements. This rapid pace of releases is great to get new features to users quickly.

Release numbering

Along with this, I also propose to accelerate a bit our release numbers this decade.

This summer we’ll do Blender 2.90 (new particle nodes), and in summer 2021 the Blender 3.0 series begins! By then we will implement a more conventional release numbering.

I suggest to do minor releases (3.0, 3.1, 3.2, … 3.7) for two-year periods, and then move to a new major release. Blender 4.0 could be there in 2023 already!

Below is a summary. Let us know in the comments below what you think!


Proposal: 1 LTS per year, major release cycles each 2 years

2.8 + 2.9 series wrap

Finish the original 2.8 targets and focus on polishing for the first two LTS.

3.0 series

New numbering, after 21 years the Blender 2.x series gets a wrap!

4.0 series


Ton Roosendaal
Blender Foundation chairman

127 comments 45,945 Views
  1. I think it’s very good news.
    A more professional and reliable development of Blender for studios and users.
    Thank you for your great work

  2. Big news! Can’t wait!

  3. Great news about LTS for professionnal uses! (and also addon-devs-on-spare-time who may not necessarily follow to frequent updates).

    Is forcing a release cycle on a specific date could’nt bring to bugs not fixed, due to a rush? Unless forcing bug-only-corrections one or two month before the release date (which I suppose been considered actually 🙂 ).

  4. Why not Blender YY.MM ?
    For example “Blender 2020.2”

    • to be more precise, then YYYY.M

    • Agree with you. IMO, using the same release numbering as Ubuntu (for example) would be more clear.
      Otherwise, making LTS versions of Blender is an excellent idea! Looking forward to see a ‘20.05 LTS’ version! 😉

    • 100% agree. I like what Ton’s proposing but it just cries for a YYYY.MM version. Otherwise we’ll end up with ‘Blender 5.7’ and somehow having to know the last LTS was ‘Blender 5.4’… YYYY.MM is what they are looking for, and they should make it so that first release of the year (like 2021.0) is always the LTS version. That way it’s clear.

    • I like this because it makes it easy to navigate the versions of the seasons.
      For example. When did blender 2.5 come out? When Blender 2.8 came out, does anyone remember? A couple of years ago, but if the name were Blender 2019.07 or 19.07 or 19.7, it would be very easy to find out which year this version of Blender came out.
      For example, Blender 2.5 = Blender 2009 or 09 or 9.
      Of course, no one will rename the old versions, but new ones are possible.

    • But this is not critical, even if it is called as it wants, I will love equally Blender 3.0 and Blender 21.8 🙂

    • 100 percent disagree. That’s ugly to read and harsh to understand.

      I love the version proposal, simple and effective 🙂

    • We looked at both options, either following dates or numbers. To me (and in feedback with developers) it appears that a bit more mlestone-based planning would fit Blender better. We then can even slip the calendar for a big update that way, and make the ‘3 series’ and ‘4 series’ truly memorable.

      • I also agree with following the Ubuntu numbering methodology, particularly where LTS is right in the name. As a manager who is converting my small studio to Blender this year, I am very intent on jumping into the first LTS release and staying there.

      • That’s truly amazing sir, I’m new to blender this month and I’ve watched so many videos about you ( mr ton roosendaal ) and the entire blender foundation. I’m honestly amazed by the togetherness that you all have and I’d love to join the family God knows. It’s literally the best in the world to me rn

      • Ton,

        I understand your point of speaking about an upcoming 3.x, for which you don’t know or can’t promise a fixed release date. So delaying an already announced 3.x version is simpler than announcing a 2020.05 LTS version and then have to skip to say 2020.07 LTS instead.

        BUT (there is always a BUT, right?)

        As I understand the LTS version is going to stay for a longer period, say one LTS each year, staying alive for another 2 years. So you are firmly covering two LTS releases at a time. If thats the plan, why not speak of 2020 LTS, 2021 LTS etc., while having the “monthly builds” being the 2020.05, 2020.07 and so on.

        If you plan for an LTS release to arrive early in a year, its unlikely you will need to delay it to next year. And if that really happens, who cares? Then its going to be 2021 LTS. At least as long as we know what we are talking about thats a good thing.

        Honestly years in the naming make so far more sense than anything else. And its a consistent naming scheme. You coun’t your age in years, not in versions, right? 😉

  5. I love the LTS this is fantastic.

    I like the releqse numbing a lot better than the previous Blender releases. I’m curious if other versioning was considered such as Semantic Versioning?

  6. The move to YYYY.MM releases is not a bad idea.

    However, I would also point to the python model that major version changes should be for major (api breaking) changes. In this, 2.80 should probably have been a major version as it changed so much.

    But IMO moving to a version 3.0 just because “it’s time and we hit 2.9” does not make as much sense. The change of animation nodes might be a compelling major enough change for a 3.0 though.

    I guess I’m saying “be flexible”! And save major versions for major breaking changes.

    • I’d agree if blenders development worked in a compatible way, however compatibility breaking releases are still too likely to happen too suddenly for the foreseeable future I suspect, once they have nailed that down a bit more as well, perhaps this can be reconsidered.

      • It’d be nice to have a seperate API semver so that devs could support major version ranges with no fear of breaks.

  7. Why go from one completely arbitrary version (2) to another completely arbitrary version (3) when you can also use that chance to switch to a more common format like Blender 2020.3? Lots of software using that nowadays, as it makes it much simpler for users.

  8. LTS makes sense. But that will not satisfy people expecting design fixes.
    People in desperate need of a new feature fixing their workflow will download daily builds.

    So, if now, people are using LTS or daily builds : what’s the point of continuing to make a new release every 3 months ?
    People will probably skip 1 or 2 of those quarterly releases between 2 LTS.
    From users perspective, those releases are useless.
    It is probably a good thing to alternate changes/additions periods and bugfixing periods from developers point of view.
    But I don’t think that makes sense to make a release at each alternation.

    Currently , people are confusing current alpha, current beta and experimental branches.
    Documentation will probably only follow LTS.
    Features of in-between releases will be missed by people, like it is already the case. Many users are missing features from releases they skipped.
    Only 1 or 2 in between releases will be sufficient.

  9. So we these changes there will be no more big milestones since the versions jump will happen quickly?

  10. YYYY.M makes much more sense

  11. So fast 4.0 in few years, is it balanced decision? IMAO 3.0 such a great number for to be LTS.
    And also i think numeration below was little bit intuitive.
    August 2021 3.0
    November 2021 3.01
    February 2022 3.02
    May 2022 3.1 LTS
    August 2022 3.11
    November 2022 3.12
    February 2023 3.13
    May 2023 3.2 LTS
    August 2023 3.21
    November 2023 3.22
    February 2024 3.23
    May 2024 3.3 LTS
    and etc.

  12. LTS is great news for studio adoption. But if there was a time to jump ahead to 3.0, it was back when 2.8 came out. I believe we should stick with the slow-and-steady approach (improvements until 2.89, a bigger improvement for 2.90, and improvements until 2.99 before a major update for 3.0 in about five years). The number doesn’t matter but it’s helpful to give consistency with tutorials, courses, books, and other learning resources. After 3.0 comes out in five years, feel free to jump onto a faster numbering timeline like suggested. I would ideally suggest using the 2.90 and 3.00 releases as times to make major changes to the UI and workflow, because every few years that will become necessary as the features outgrow its UI. Jumping the gun and bragging about a flashy new version number at SIGGRAPH isn’t a reason to break two decades of numbering consistency where each series runs from 2.x0 through 2.x9 with a major improvement in between.

    • 100% agree!
      There is no need at all to change the 20 years old numbering convention, just out of impatience. Having LTS is great though, but we should stick with current convention.
      2.9 series should mean a major (non-backward compatible) version. Then 3.0, then 3.1 etc.
      No mater even id it takes 5 years from now to reach 3.0.

  13. As someone who is always using the latest builds, I’m not exactly thrilled for it, because I suspect that this will lead to some add-ons only supporting LTS releases & a generally more fractured ecosystem. I can see the benefit for studios and understand the decision (although I had hoped that studios would instead opt to build their own versions and try to keep them roughly up to date with master, to prevent situations were overreliance on old software leads to stuff like the Python 2 / 3 debacle on the VFX reference platform.)

    As to the new naming conventions, I hope that a YYYY.M scheme will be adopted instead. It’s easier to explain and gives you a better understanding of the age of the software version.

  14. This is a great idea! because the quick access to versions 3.0 and 4.0 will give best result for each user of the Blender and better speed in the final result. Thanks!

  15. I think this new naming is meaningless, for me, a Blender 3.0 is not just some random release, it’s a major feature added to blender (like the come back of the BGE?), same thing for a 2.90 (this one is okay thought, with the node based particle system ^^ )

    It feels like it’s going to be rushed and there will not be new big features…

    Just stick to the old naming system please ^^

  16. Please NEVER with the year versions !!

    This leads to crappy relases just to be on time, and perdon me but 3.2 is much more clean and easy to understand than 2022.02 !

    Also, working in let’s say year 2023 with a version call 2022.02 is more annoying that running your simple 3.2.

    Rahh, can’t even believe I have to argue that timed released are bad…

    • Who talked about specific timed releases? Unlike Ubuntu with their April(X.04) and October(X.10) releases blender releases would still happen when they are ready, but by making multiple, if need be smaller, releases a year we could conceivably have a yearly release without the issue you are bringing up.

      I am however personally inclined to make the argument that versioning should just stay what it is and the LST releases could be the only ones with the yearly release name – that is it wouldn’t even be versioning – just an extra way to make the LTS’s more obvious and set apart from the bleeding edge releases.

      So something along the lines of:

      blender v3.0
      blender v3.1
      blender v3.2
      blender v3.3 LTS 2022
      blender v3.4
      blender v3.5
      blender v3.6
      blender v3.7 LTS 2023
      blender v3.8
      blender v3.9
      blender v4.0
      blender v4.1
      blender v4.2 LTS 2024

  17. IMHO whole and half numbers seem like better canidates for LTS support IE: 4.0 & 4.5 would be LTS, and everything in between would not be.

    • Absolutely, this would be more in line with industry conventions and thus less confusing for casual users. Moving the LTS from 2.93 to 3.0 and then having a new LST every 5 trimesters would lessen the patching overhead to the developers. Additionally, there would not be needed to jump from every x.7 version to a big x.0 release, which is a bit odd.
      Please consider this.

  18. Blender is going more and more towards the industry standards: regular releases, LTS and competing with others. Mantaflow fluid sim et al. Great job!

  19. I am planning to write 2 books but now I’m having doubts with the extreme name change.
    1. it is hard to communicate using version numbering
    2. major changes are not marked as a big number change ie: 3.0, 4.0
    3. sales of any education product will drop when there is a major change, unless there is no breaking feature between major versions, ie blendfile still usable
    4. fragmentation in add-on development
    5. fragmentation in tutorials, some will make LTS tutorial, some will make daily build tutorial, very confusing to newcomer.

    What I propose as a tutorial maker and someone with add-on development stakes:
    Do the normal numbering: 2.83, 2.84, etc
    When there is a big breaking change… jump to 3.0/4.0 and make the last version (ie: 2.84) the LTS.

    • The thing is, even the fairly quiet improvements within the 2.8x series did break things, like, Mantaflow breaking all of old physics. Which means that basically *everything* would be a major new version, at which point it could just use browser numbering.

  20. LTSes surely are a big plus, though I’m not entirely happy with the version numbers.

    I think I would prefer “Blender Studio 22” or “Blender 2022 Studio” for Blender 3.3 LTS, with subsequent patches being 22.0.x. That makes it super clear that there is only going to be one of those per year, and that it’s targeted at big studios. If you wanted to make it extra clear that those are supported for even longer than the one year, maybe even “Blender Studio 22 LTS” would work.

    The downside to that would be that it puts the STS versions into a strange spot, since the LTS isn’t at the beginning of the year, but rather somewhen in the middle of spring.

    Names I’d like for the STS versions would be “Blender Creative 22.1”, “Blender 22 February Creative”, followed by the LTS/Studio version, followed by “Blender Creative 22.3″/”Blender 22 August Creative”? As I said, there isn’t really a good name for them if they need to be kept in line with the big yearly LTSes. Maybe even keeping “Blender 3.x” for the STSes would be better.

    The reason I’m not too big of a fan of having 3.3 and 3.7 be LTS releases is that the numbering feels odd. .3 and .7 are right in the middle of something, they just don’t sound like versions that would be any more stable than any other version, in particular the .0 releases (Big new version that fixed so many nuisances of the old version it deserved it’s own name!), or .9 (or even .99) releases (version that’s so close to done, it’s only missing a few touches!). Further, it feels like 3.0 and 3.7 should be more closely related to each other than 3.7 and 4.0, after all, the first number changed! But as I understand this announcement, that may not actually be the case: While more experimental projects may be tackled at the start of the release cycle, there’s only so many resources to get them done. So the many, many “small” improvements between the in-cycle releases my result in a much more significant change than the one or two experimental ones.

  21. This being a radical change for Blender’s versioning system/naming as well as planning, I think it should adopt the following format:

    [Year of Release] . [That Year’s Quarter]

    E.g. Blender 2021.1

    (Released in the 1st Quarter of 2021)

    What would this change mean for LTS versions and their release schedule? In my opinion there are two options:

    The first LTS version would be the November 2020 version 2.91 LTS, making it the last version of the current versioning system and a clean closure to that chapter and year with an LTS release. Starting 2021, the new system gets introduced with 2021.1 in February 2021.

    Concluding the year 2021 with Blender 2021.4 LTS release. Making the “20xx.4” releases the LTS release.

    OR

    Old version ends on 2.91 in November 2020. In order to deliver the new versioning system and LTS at the same time, the introduction for both systems would start at Blender 2021.1 LTS. Making the “20xx.1” releases the LTS release.

    Here’s why this format be a good option in my opinion:
    • Blender versions become easily identifiable (Granted it will require explanation of this system with its introduction). Users immediately know what year and which quarter of that year a given version of Blender was released. No need to look up the release dates.
    • Although a more jarring change at first it creates an easy to memorise and visually consistent system for the years to come.
    • Both scenarios move back the LTS release from the currently proposed first release giving the team few more months to plan the first LTS release.
    • Both options presented above for the LTS schedule make it easy to know when the LTS release is coming; either at the start of the year in the 1st quarter or at the end of the year in the 4th quarter.

    I personally find the “20xx.4” release as LTS more logical since every year there will be a set schedule for changes/fixes made in Blender over the course of the year and near the end of the year the team could focus on polish and final bug fixing for a nice solid LTS release to conclude that years efforts.

    Also, some might argue that the “.x” should follow Zero-based indexing (from 0 to 3), however if the focus is to improve the versioning system/naming, One-based indexing is a lot more appropriate for a wider audience. Even though Zero-based numbering is a simple concept for a developer it isn’t necessarily simple for someone that isn’t one.

  22. I like the idea of LTS-Versions but hey, why change the versions so drasticly fast now? Is there really a need for that? It’s such an intensive Blender-time it’s important to keep some parts steady oherwise people gets confused to much.
    And does it make sense to end with a crooked number for LTS? Why not start with a even number for LTS-Version. So instead 2.83 LTS it will be 2.9 LTS. Every new followed release will be than 2.91, 2.92 and so on. So you immediately know 2.93 is the third release after LTS. Next LTS Version will be 3.0 and 3.1 and so on. This is much clearer to for my unterstandings.

  23. It’s whatever blender foundation needs or wants to be, I don’t care if there continues to be 1 or 2 versions, I only care that it grows and stabilises and pushes forward for all users, I don’t care if studios want an LTS or anyone making money from it is getting an LTS or whether it changes its naming convention to the year

    I expect something other than industry equivalence & accepted conventions, blender just needs to be what is to us users of the tool for artistic purpose.

  24. As long as the LTS version doesn’t impede on blenders continued growth and isn’t being guided by industry wants & needs the blender should continue to evolve at the pace it has been Im totally not in favour of year release numbering I find it lacking in interest, it’s a money making excercise which is not blenders arena. Stick to the existing plans 👍

  25. Couldn’t they jump the 2.93 and make the LTS always 3.0 and 3.4 ?
    3.0, 3.4, 4.0, 4.4 makes more sense then 2.93, 3.3, 3.7, 4.3, 4.7
    Anyways… this is good news.
    But I kinda get bugged with the LTS being always the 3 and 7 instead of the 0 and 4.
    Is it just me?

    • We are planning annual stable releases (LTS’s) and it seems to communicate better if we do that based on the major release number. That means we plan 3.0 , 3.1 and 3.2 to more exicting and 3.3 to be the LTS to wrap the year.

      • Hey Ton,

        I have a question, and it comes from a non developer point of view, so maybe I’m going to write something stupid…

        I like the two year cycle for a major milestone as well as the new number versioning scheme. But for the long term support release, wouldn’t it be better if the first LTS of a main branch starts at x.1? So that professionals and studios can get access to the shiny new stuff sooner, after three months instead of nine?

        Also, making a first LTS at x.1 would still give you a three months period to iron out and fine tune the initial big branch release. Then the second LTS at x.5 would still come with subsequent new features of the main branch while not miss out too much with the last x.6 and x.7 releases, where you could start experimenting with more “heavy stuff” that would be included there or in the in the next big x.0 version if it needs to be postponed.

        Maybe it is just me but I would not want to wait for nine months to get the first LTS of a main branch. So, I’m rooting for x.1 and x.5 LTS releases. It feels more attractive like that I think and also less “odd” regarding the LTS number versions… Take that as you will 😉

        Keep up the good and awesome work you are all doing with that beloved Blender!

        Regards.
        David.

  26. Am I the only one that doesn’t like this new numbering scheme? I’m not against the idea of LTS versions, but I think we need a more predictable numbering scheme. Here are the version numbers after the LTS releases:

    2.83 LTS –> 2.90
    2.93 LTS –> 3.0
    3.3 LTS –> 3.4
    3.7 LTS –> 4.0
    4.3 LTS –> 4.4

    Maybe it’s better to stick to the old numbering scheme? This gives you more flexibility on when to release LTS versions. I’m not so hot about the proposal of using the year as a numbering scheme either. 2.79b was released in 2017 and 2.80 was released in 2019. If the blender organization are working on major releases, they might have to skip a year and that would be confusing. I’m someone who doesn’t upgrade my blender versions regularly and prefer to use the bug fixed releases, for example 2.81a instead of 2.82. People who have Linux will sometimes want to compare their repository versions and blender’s official version history to make sure they install the versions they want.

    Also, what does this mean for non LTS versions? Do they have the same quality standards for bug fix versions as before?

  27. A few points:

    We do not plan to do another release like 2.80, where we change many different areas at once. However I believe the combined changes over 8 releases will be just as big and worth the 3.0 version number. We just aren’t going to artificially hold back features to put them in one big release, but LTS users will have the option to wait.

    We will work to make every Blender release more reliable than the last one, regardless of the LTS. My aim is not to have a stability reset like 2.5 and 2.8 ever again, but rather to do major changes in a more careful way and improve our QA and testing. For example particle nodes may take a while to become production-ready, but we can keep the old particle system alongside it until that happens.

    The LTS version would be last release in the release series, since the first release would contain the most breaking changes that may need further polishing to be supported for a long time.

    • Thanks for the input. Great to hear that about non LTS versions. I understand that the current numbering system isn’t that great for marketing and general public perception outside the Blender community, but at least it doesn’t confuse people in terms of updating Blender. I think one needs to balance marketing version numbers and public understanding/usability of versioning systems. I suppose there really isn’t anything better than what Ton proposes with removing the last digit. I think the source of my initial dislike is because companies have abused the number version system for marketing purposes and made me cynical about version numbering where little updates/fixes get major version numbers and skips update numbers. Skipping update numbers often don’t make sense. I appreciate that Blender does the opposite of commercial software. They over deliver in version numbers instead of under delivering. If the general public can better identify a bug fix version, a minor updated version, and a major updated version, then this new system with number skips might not be that bad.

    • Problem is that a too short release cycle does not let to users enough time to do more than cube testing before release.
      You will not improve reliability of releases by keeping a 3 months cycle.
      Average user working on his own projects during the week, just has 10 days of spare time to spend on experimenting with new features before release.
      Because of impressive amount of features added per release, he will not play more then 2 days per feature and will test all of them. Half a day can be dedicated just to read documentation or following a tutorial.
      So, most of bugs are discovered after release.
      You should increase testing period.
      You should release LTS,
      then, 4 months later (to respect always at least 4 full weeks for Bcon1, Bcon2, Bcon3): a release candidate
      1 month later : a stable release at end of Bcon1 of next release
      3 months later : a new release candidate
      1 month later : new stable release at end of Bcon1 of next LTS
      3 months later : new LTS candidate
      1 month later : new LTS release
      3 months later :new release candiate
      etc.. SO a 3 + 1 months cycle instead of a 3 months one

      • I don’t know if I was clear. In other words, I think that a reliable release every 4 months is more realistic than one very 3 months.
        I also agree with people saying that 2.83 will not be a good choice for an LTS.
        Not just because it is an odd number but also, because there are too many 2.8 design todos not accomplished.
        Texture Baking in 2.8 is not satisfying.
        2.8 redo panel is not satisfying.
        Texture painting is not satisfying. Undo, Mesh editing of high polycount, etc…
        Multi-object editing is still experimental.
        OK! Everything nodes can mark a passage to another series. But particle nodes is just a chuck of what is supposed to happen next.

        So, it will be better to wait to have satisfying basics before picking a 2.8 release as an LTS.
        If technical debt and basics of 2.8 design are stabilized in an other release after LTS, nobody will use it for production. So, what will be the point to assure a long term support for it.

  28. I been a blend head since 2005. I was stun to see a 3D program for free “Blender” ,while I was wondering how would I learn 3D modeling when Maya and 3D max are expensive to buy. Thank to all who were and are involved with blender development . It had change my creative ways a lot easier then those early days . Now, I had email Ton Roosendaal
    Blender Foundation chairman > that while development to branch out a new working system for blender. Call “win-graphic system workstation”. a window system that will run blender more efficient and faster render performance than regular Microsoft window system. The new window system should be part of the L.T.S support. unlike Linux it beginning add more junk files which inference with blender files sharing Dll.and ect. win-graphic system should just be clean of unnecessary files only be blender and render-farm opensource programs and commercial. It time to cross that new frontier with Blender.

  29. Awesome announcement! I’ve been using blender since the bad old horizontal layout days, and it’s so exciting to see all the good things happening in blender development, so thanks for the update and all the hard work.

    Curious if the LTS versions would also include a bug fix release number(i.e. 2.83.XX), and if so would it then make sense to extend that to regular releases that require a critical update vs (a,b,c releases)? Just food for thought.

    • I absolutely agree. I think already to start producing LTS 2.81 (b/c/d…). She looks stable.

  30. I support all of these plans including a new much more logical numbering system which I have argued for, many times.

    But also overall, so great to see an open and transparent development roadmap!

  31. Here’s a scenario that might happen with the LTS.

    CUDA driver not working with LTS, or newer CUDA version needed for other software but you are running the old version because Blender LTS.

    Or Windows just one day decide to update your gpu driver and break your LTS.

    This happened to other DCC with LTS. I’m not sure how the devs are going to work with these since anything outside of Blender will break the LTS.

    The other possible problem with LTS, more add-on version to maintain. Some version will not get updated.

    Another will be confusion for linux package manager.

  32. Simple numbering as suggested in the post is great. Lets not go with a year as some have suggested here in comments. It should be timeless. Rather the number represents a certain state of the software. Its always gross when companies go out of sync with the years (either get too far ahead or too far behind). Plus it smells commmercial, especially when you have 2026 release in year 2025…

  33. These are great news!

    About the version numbering debate, here’s my view on the topic. As we can see on the proposal in the post, arbitrarily choosing versions *.3 and *.7 to be LTS feels a bit strange. But more importantly, this type of versioning is good when big/breaking changes happen in major releases (3.0, 4.0, …) and minor changes in minor releases. This is imo what people expect when they see this kind of version numbering.

    However, Blender evolves quite differently, and as @brecht said earlier, there are no plans to make another big release in which everything changes at once. So I think the numbering by YY.MM is better overall, because at least it conveys some relevant information (when it was released). Some said that if feels commercial, however I don’t agree, that’s how Ubuntu has done it forever, and it works great! It becomes commercial when version 2021 is released in October 2020, because then the “conveying the release date” part is completely lost in favor of marketing.

  34. The Cycle will be faster but will the higher numbers like 3.0 or 4.0 also bringt
    advancements that justify a new version number?

  35. Thanks for a LTS. Following breaking changes is hard and you need that for studios. A LTS version brings less management around it and that’s nice.

    I’m curious about how it will impact stability contributions. I have no internal details, but I hope LTS version would make professional contribution “valuable enough” to invest time in bug fixing. Finger crossed.

    About version number, I don’t care. An important information between each LTS release would be “what is breaking”.

    Keep the good work teams !

  36. Why not just change 2.83 to be Blender 3.0 and make it LTS? Every year release the next LTS as a full version number or even a 0.5 version number ie 3.5, 4.0, 4.5, 5.0 etc. Forget point releases as official and just keep the in-between versions in experimental. 3.0 drops as LTS. In experimental we get the daily builds for 3.5 Alpha until 3.5 LTS drops a year later. Just because it would be in experimental and be labeled alpha doesn’t mean it has to be lower quality than current point releases. This could allow the devs to rocket forward and try a lot of new things.

  37. Would be nice to be able to upgrade to the next version, as opposed to reinstalling it, add-ons and all. Could there be two downloads, for an upgrade from the previous release, and a fresh install? Re-installing every add-on may be cumbersome to the point of discouraging upgrades: I’ve just installed 2.82, for example, both on MacOS and Windows/bootcamp, and now dread the thought of doing it again for 2.82a.
    Also—and I will never stop requesting it—think about supporting Metal 2 in Cycles for Mac OS. AMD can do it in their Radeon ProRender; why not BF in Cycles? If an LTS writes this anti-Mac tendency in stone, I swear to God I’ll switch to Maya. ☹️

  38. But why the rush to turn 2.83 into LTS? If this is gonna be used for long term productions, wouldn’t it be better to wait for a Blender with a working Undo? The moment a project is getting larger it cripples the workflow in many cases, So for big studios, this is gonna be not so fun to work with

  39. First off, Amazing job guys. I would suggest that LTS be created specifically for studios while, individual artists could continue with the regular release cycle. That way studios have a more stable and supported versions (LTS) and Individual artists can pick whatever versions they feel like using, That way fragmentation of users, add-ons and tutorials (which is already happening) wouldn’t be that obvious. Add-ons would take a hit as developers would have to keep updating the plugins every three or so months and some developers would rather just support LTS. Studios should get stable and supported versions while individuals get to pick what they want. That’s my suggestion

  40. LTS = great

    but this jump every year to a new version feels wrong. A new version number should be more like a new generation

  41. This feels like turning into subscription model, where each release is a point release….goodbye milestone releases, no more big hype.

  42. A material editor for terrains is needed, there is an option ‘Material’ in the A.N.T.Landscape, but it is empty.

  43. don’t do too much for the studios, they keep this for them.. it’s reassuring and an industrial manner ok.. BUT there are pretty more users along..
    Also the Blender 3.3 is ok then the maintenance of LTS makes it Blender 3.3 LTS22 (only the decade)..
    Then the next ones will go on old num: Blender 3.4 ..etc
    The LTS keeps being a special version for a majority.

    • in fact the LTS ones are meaning better sup for studios AND
      could be their practices, their own tools shared!
      this means Blender 3.3 LTS22-AMD or even Blender 3.3 LTS22-Tangent etc
      their own marketing shared for all with exclusive tools included .. (perhaps finding more about animation others on modelling etc)
      ** but really the best should be the add-ons included with their own brand ok.. not the Blender LTS all at once, add-ons is to be the next great advancement with studios, sharing their own internal tools as a challenge: this could be planned with Blender Foundation to get the best pro add-ons (also well used and ergonomically with pro too…)
      ** and inside a LTS there will be the bonus of AMD, TANgent own PRO add-ons, this could be the starting next ver as 3.4 will be using the LTS engines. And this could be the tech contribution, challenging their internal teams “against” others to get a prime add-ons. Industries like challenges coz of ad it creates.

  44. I like your proposal a lot more than what some people are suggesting. Using YYYY.X for versions is a bad idea for blender. For example “2021.3” version would be very bad to say and write, it’s too cluttered for content creators. That would only be good for slow moving software like Photoshop as they don’t have as many changes, and updates are somewhat yearly. Perhaps it would be an option for LTS, but in regular Blender releases, updates are something we regularly hear and talk about, so a simpler and cleaner form is important.

  45. It may be better to use 3 numbers:

    3.0 -> 3.0.0
    3.1 -> 3.0.1
    3.2 -> 3.0.2
    3.3 -> 3.0.3 LTS and fix releases (3.0.4, 3.0.5,…)

    3.4 -> 3.1.0
    3.5 -> 3.1.1
    3.6 -> 3.1.2
    3.7 -> 3.1.3 LTS and fix releases (3.1.4, 3.1.5, …)

    4.0 -> 3.2.0
    4.1 -> 3.2.1
    4.2 -> 3.2.2
    4.3 -> 3.2.3 LTS and fix releases (3.2.4, 3.2.5, …)

    4.4 -> 3.3.0
    4.5 -> 3.3.1
    4.6 -> 3.3.2
    4.7 -> 3.3.3 LTS and fix releases (3.2.4, 3.2.5, …)

  46. I agree with Grigoriy there should be three numbers but the third octet should be bug fixes for that version.

    X.Y.Z

    X = Major Release
    Y = Addition Features within a Major Release
    Z = Bug Fixes within that Feature set

    Currently, Blender does this with versions A and B but I believe to standardize it using the third octet would be better.

    • I agree with this format except to change “Major Release” to “breaking changes” which would follow Semantic Versioning very nicely. https://semver.org/

      • Yeah Semantic Versioning makes it trivial to tell what each version does and why it was released.

  47. Currently LTS for Blender is meanning nothing for users, If you want for professional support so I propose you need and you will make every year at starting 3.0 new big release as other company plus somes fix as regular every month (update some machine, Cuda, serious bug, etc…). I understand there are so much of work you make Blender that I say every year a new big release as you can to have plenty of time to refine, everyone and your team is win-win for users, company and you.
    Or If users want a little more productive from you so a suggestion is to make every half year or six month and the number are 3.0, 3.5, 4.0, 4.5, etc… Number for 3.0 is a majors big news featuring and 3.5 is minor featuring, and so on as 4.0 big and 4.5 small etc…
    Because here as i say is more meanning than the currently LTS for Blender.

    What do you think from that ?

    Thanks and keep it up !

  48. Why everything so complicated?
    Ask yourself who uses Blender mainly, and who made Blender what it is today! By far the most users are private individuals and the semi-professional sector (as well as in smaller studios)
    And it has to be as simple and clear as possible for exactly this target group, and with quick bug-fixing.
    My criticism is that 2.8, 2.81, 2.82 have far too many bugs to wait 3 months to fix them. If you have a problem and switch to 2.83beta, most of the time the actual problem is fixed, but you have many others, and it doesn’t make any sense.

    An LTS version makes perfect sense for large and critical projects, but you have to skillfully balance both stability and fast bug-fixing.

    I would suggest that the initial releases, such as 2.80 or 2.90 etc., be kept as LTS versions (2.8-LTS), with fixes for critical bugs and driver updates. Between these LTS versions there are daily-stable builds with current bug-fixes, like 2.81, 2.81a, 2.81b… until the 2.9LTS release.
    This way you keep the familiar system, stay organized, and avoid version number races.

    While a LTS release is started, e.g. 2.8-LTS, the 2.9-LTSbeta is being worked on as before. When to change from one LTS version to a new one is decided by the quality/stability and the new features; so everything as before,only with a back-porting service for the LTS versionsonly with a back-porting service for the LTS versions and faster availability of buf-fixes for users
    (that was probably the original idea…)

    Please always remember who uses Blender mainly,
    even if big studios put millions on the table ; )
    The main focus on the users and a portion of service for the studios : )

  49. Very good news!

    It’s the time for leave from others 3D packages (Autodesk, Maxon, The Foundry) and start a new pipeline with Blender+Houdini. Now I can across from XSI to Blender without problem.

    The future is Orange… is Blender 😉

  50. THE MADNESS!!!

    By Year 2030 well be at:

    Mozilla v98234234234234546
    Chrome v99456456345345353
    GCC v99534573466675347
    Clang v93554934593495394
    Blender v935349534959349539459349593495934593495934…..

  51. Amazing ! Perfect timing for announcing a LTS version: we had a discussion last week at Ubisoft Animation Studio about sticking to a specific version vs. updating every three months. People in animation feels more safe to choose a version for a project and stick to it, but I was arguing that we would miss important bugfixes by doing that. Now we can just decide to choose the LTS and everyone should be happy 🙂
    Keep up the good work !

  52. This is a very good direction. LTS will allow Blender devs to stabilize over time a main stable version all in keeping developing and bringing innovative technologies for testing and acceptation by users before integrating them into main LTS versions.. Such a management will also allow for adapting to technological evolution in hardware and languages.. Also it will probably allow for branching of Blender toward specialty applications such as CAD, Robotic, architecture, medical simulation and so on.. Blender is becoming adult and has a very long life ahead.. What an adventure… It will probably be a business case in the future…

  53. Personally, I would strongly prefer either YY.MM (like Ubuntu) or some other more continuous numbering system. It gives more consistency between releases, and at least to me, something like 22.05 LTS seems more professional than 3.3 LTS. It is richer in information, stating when the version was released as well as when support will end. A lot of professional software I know of with regular releases has this sort of versioning scheme (e.g. 2015 LTSB for Windows 10, YYYY.MM for most Autodesk products, YY.MM for Ubuntu, etc.). Personally, I also find YY.MM more visually appealing than X.X.

    • I couldn’t agree more, if going from 2.9 to 3.0 does not involve more changes than going from 3.0 to 3.1 then this versioning method makes no sense, YY.MM is much more logical and at least carries some useful information…

  54. I was a C4D user for a few years. Since 2.8, I’ve never looked back. Glad to see the momentum and support behind Blender. Further cements my decision!

  55. Hello!
    I’m a student and I’ve been using Blender for 3D modeling for the past 6 years and I love it, specially now with 2.8 being so powerful and getting a huge corporate support like it deserves. Blender is surely setting a strong foot in the 3D industry and I believe it can be the near future for companies to adopt it instead of the other solutions.

    However, I’ve always been wondering wether or not you guys would implement an updater/launcher that will update the application whenever a new update is released, because downloading the full installer and installing over the other someone sometimes can corrupt files and create instabilities. I believe an updater would be more efficient to both parts, and I’d like to see one emerging personally.

  56. The one thing that doesn’t seem to get too much mention is the THIRD PARTY developers (ADDONS). There is so much talent out there (FREE) and with so many changes happening with Blender lately, it may become very discouraging for them to constantly update their ADDONS which would be a real shame. It takes time to create these great ADDONS for Blender and they do it at their own time and expense.
    Let say a 6 month turn around would make it more of a stable situtation.

    “Just a Suggestion”

    Cheers
    MR HOLLYWOOD

  57. We have usd, alembic, fbx, working on vdb. Changing internal structure of blender is not a bad thing and everyone should accomodate to it (because of how easy now it is to export anything). Also blender is not like Linux kernel and probably doesnt need lts version 😅 bleeding edge is way to go, also if lt is released, what version users should download? Is someone want ‘stable’ and not changing version I’d suggest to download one old version and stick to it.

  58. Blender was assumed to be an in-house design tool. The richer the donations are from bigger companies, the further away Blender might get away from its community. It looks like these big companies first donate a lot to open source projects. Then they send “reasonable” requests such as “we want an LTS release”. Sure, why not? And the moment this creates a burden on the shoulders of the developers, is the moment when the companies gonna say “you know what we decided to cut our budget”.

    This is how big players “buy” unbuyable softwares like Blender.

    I hope I am mistaken. Just keep an eye on that issue, guys.

  59. When there is a minor update, the version is added by 0.01, and when there is a major update, the version is added by 0.1, and when there is an unbelievable update, the version is added by 1.

    Let me explain:
    Blender 2.78 + 0.01 = 2.79 and it was a minor update
    Blender 2.7 + 0.1 = 2.8 and it was a major update and everyone knows it
    Blender 2 + 1 = Blender 3 and it will be a wonderful and unimaginable update, trust me.
    Same for Blender 4

  60. To reduce the work-load on add-on developers, I suggest introducing an LTS-ready category for add-ons. Thus, a developer can *choose* to promise Long-Term-Support, but also have a bleeding-edge non-LTS version for the intrepid users. Of course, the promise should be backed by the add-on API remaining backward compatible within an LTS period. For example: LTS-ready add-ons written for version 3.3 LTS shall also work for version 3.6 without modification but may need updates to work in version 3.7 LTS whereas non-LTS-ready add-ons may only work in specific older or newest Blender versions).

  61. Should an LTS version be preceded by a Tracker Curfew?
    [[https://code.blender.org/2019/12/tracker-curfew/]]

  62. I always liked Blender’s existing versioning standard, with numbers increasing very slowly. It distinguishes it from the bad habit of commercial software projects, always trying to raise the number for marketing purposes.

    Adding +1.0 to the version number every two years does not actually add more features, and we’ll be up to version 10.x sooner than you think!

  63. LTS is a good idea. Means there’s very little worry about cross contamination of versions. I approve.

  64. So you guys are going to jump two versions each time like x.8 & x.9, it best to do from x.1 to x.9 and full number version as the LTS, otherwise you’ll confuse a lot of people.

  65. NOOOOOOOOOOOO !!!! (in a Darth Vader voice, just to be clear)

    Blender’s version increments were my favorite !
    It’s a great way to ensure clarity on milestones in the long run.
    If free software is meant to last for decades, then 50 years from now, when Blender reaches a new big milestone, how could the version number suggest it?
    From 27 to 28, you can’t tell if something important happened by just looking at the version.
    On the other hand, from 6 to 7, you know it’s a big deal.
    There are huge milestones to come in the next century. We are so far from the end.
    If we start numbering like this right now, we’re setting it up to look ugly and harder to memorize in the distant future.

    I’m generally on board with fitting in the standards. I like consistency and universality of software. I just don’t see any positive outcome in this particular case.

    LTS is great though. Fully with you on that.

  66. Has there been time that blend files could not be read by the next version of blender ?.

    Your now promoting poor IT management as a versioning problem into Blender.
    You should not do that, its not who GIT works, it should be only fix and features based.
    We might be 2 years on 2.85 before 2.86 or a month, depending how things get fixed and code aproved. Dont spend valuable resources on maintaining bugged versions, focus on going forward.

  67. Please avoid the ridiculous style of Chrome and Firefox versions.

  68. You can keep the current numbering system. For Long Term Support versions just add LTS to the end and then you can add a letter to the version. That would allow for 26 bug fix releases during the 2 years. Or you could use a designate letter. Something like 2.84L.### l for long term support and then number bug fix releases. While continuing with the current numbering system for new features.

  69. Looks great!!
    But I’m wondering when is planned to look into edit mode performance with mid-high polycount and subsurf modifier. You are planning a LTS version (2.83) and I don’t see in any report a schedule for bringing back 2.7x performance. I’m expecting in all developers meeting notes and nothing. Not all modelling is sculpt mode. I think that before introducing a lot of new features is necessary not to do same features worst than previous versions. Cheers!

  70. Everything about the new Blender is awesome and welcome! 🙂

  71. hey guys, Im learning blender since version 2.7, and can do lot of things, but I have a macbook pro, as you know its kind of slow for many things, and when I start blender for a new project or project that I´ve been worked on, starts to flickering, and still don´t know why.

    And the other question is: how do I install the studio lights, matcaps, etc?
    Thank´s for your help and keep creating =)

  72. Whooah LTS just like Ubuntu. But it makes me confuse

  73. For real, please slow down thr releases and release cycles.

    Serious blender users really don’t care about version numbering or care to poat here, because like it or not they are still on 2.79 working on their job dependent models waiting for serious function fixes, performance regression fixes, and bug fixes from 2.80. Yet blender had alrrady moved on to 2.83 keeping all the bugs and problems with it.

    Please slow down, and let your developers finish fixing all the bugs from December.

  74. I work as a Pipeline technical director in a small film studio and one of the common issues I face is API compatibility in applications. All of our software uses SemVer to encode compatability information in versions. It’s sadly not uncommon to have to support multiple versions of DCCs, and it become very important to know which version has which feature. We use a system called Rez which will resolve a version of our pipline software which works with the DCC being used.

    `rez env blender-2.8 pipeline`
    would give me a version of pipeline tools that worked with python 3, and blender 2.8s api

    `rez env maya-2018 pipeline`
    would give me the newest version of the pipeline that worked with maya 2018 and python-2

    I know this will work because each version of pipeline specifies what variant of the DCC it is compatible with.

    Blender seems to have a habit of making breaking changes to its Python API which would be a nightmare to deal in production ( I often see “this addon is not working with version x yet” ). It would be fantastic if you folks could provide a SemVer for your API.

  75. Dear Ton
    Unfortunately I’m no fan of your proposals. It is like having two Blender releases at the same time, and will only cause confusion. In addition, it leaves the impression, you are releasing software in experimental state, while maintaining a previous release for the sake of studios.
    The traditional way should do it fine. Means, one current release, which gets maintained for a longer period with regular updates. And in addition alpha and beta version where all new features are being implemented. Its the same thing, just different labelling.
    Please, keep Blender a community project for everyone. In recent years its development and public image has been focused too much on professional use. Remember all those great real-time simulations made by universities with the game engine? Gone. Like Leo suggested above, ‘Blender Studio’ might be a more matching name now.
    Friendly greetings,
    Torsten

  76. It’s interesting that some people don’t see that versioning scheme of Blender and Firefox are the same. Yes, Blender has a dot in the version string, but it doesn’t change anything. It would be the same, if it were 278, 279, 280, 283, 283. Why, because Blender version is updated by uplifting the second minor (the last number), and after 9, the first minor is uplifted and second is resetted to 0. Sounds familiar? Maybe, because that’s the way integer calculus works by adding number 1 ==> Firefox/Chrome.

    Some are blindly fascinated by the fact, that Blender major version grows slowly. But it has no other meaning that people put into their minds. It’s not better or any less marketing. It’s the same as growing number, with a dot.

    • This! Always thought that the only version number that had an intrinsic meaning was 1 and that everything after that is just, as you say, a growing number. There is a tiny advantage of having a dot in the number tho: you don’t have to write the last digit when it ends in 0 🙂

  77. I’ve used Blender since 2001, so I’m obviously attached to the old versioning scheme, but I think that doing:
    2.9LTS for LTS updates and 2.91, 2.92 etc. for minor updates is a good compromise.

    I also really just have enjoyed the excitement of waiting for the 2.5, 2.7, 2.8 releases, personally. I feel like it adds community momentum and buzz.

    Just my 2¢.

  78. How about making the LTS release the Version 0 release.

    3.0 LTS 4.0 LTS
    3.1 4.1
    3.2 4.2
    3.3 4.3

    The LTS version becomes the baseline (stable version) for the years oncomming work. LTS version, no new features, just bug fixes, UI, documentation, and bug tracker cleardown……and breadthe.

  79. Please stop guys, On arguing on version numbers.
    Remember when 2.8 released and they said they will change from right-click to letf-click, we all argue that blender was made for us not the industry,
    They never listen and changed it anyway.
    So no matter what we talk about, they are still going to do what they have propossed.
    It is pointless and total waist of time to talk about this topic.
    I don’t even know why they made this thread in a first place.

  80. I believe what would be proper is use the way Microsoft is naming their Windows version.
    They at Windows 10 but the actual version of Windows is 6.4.x.
    So we can get like
    Cover version Actual version
    22.1LTS. 2.8.5
    25.0LTS. 2.9.1
    Or maybe
    1.0 LTS 2.9.0
    So that the ad on dev can ease themselves without a task of frequent unnecessary update just because the version change.

  81. Imagine Blender 5.0…

    I even can’t wait 3.0

  82. https://downloadcenter.intel.com/download/29554/Intel-Graphics-Windows-10-DCH-Drivers

    “This driver is WDDM 2.7 compliant and ready for the Windows 10 May 2020 Update. It introduces support for Dolby Vision and the new DirectX 12 Shader Model 6.5 compiler on 7th Generation Intel Core processors or higher (Intel® HD Graphics 610 or higher).”

    Please develop and test Blender on the latest Intel WDDM 2.7 graphics driver.

  83. I can’t wait😘😘😘😘😘😘

  84. As for release numbers this was always odd in blender. As well as incompatibilities down the road especially for addons. SO THE PROJECT TEAM NEVER KNOWS IF ADDONS OR SCENE FILES WILL WORK IN THE NEXT RELEASE.

    YOU SHOULD NUMBER RELEASES BASED ON BACK COMPATIBILITY this makes things clear for the final user. For example 4.0 is not compatible with 3.0. Then 3.9 is compatible with 3.0 and addons and scene files work fine among them.

    Then a major release every 3-5 years is better for production since this way compatibility is assured for LONG TERM PROJECTS. Also IT technology follows a 3-5 years route anyway.

    I do like the LTS commit it is seriously needed.

  85. You can call it whatever you want, it will still be Blender.
    It will still be INCREDIBLE, FREE software that helps so many to learn and earn a living.
    I just want to say THANK YOU to the whole Blender team. THANK YOU. Dg

  86. Are there any plans to add support for panoramic equirectangular cameras in Eevee in 3.0? Or in 2.9?
    The button is there for it in Eevee but it’s been broken since 2.80. Would be great for making VR videos, especially since Blender is getting more VR functionality soon! 😀

  87. I have been a Blender user since the NaN days. Ton, you did the world a huge favor by obtaining the Neo Geo program, starting the foundation, raising the 100k to buy the code and leading for so long. Thank you. Having used Linux for an equal amount of time and many open source programs since, I am still convinced that Blender is the most impressive open source software project to date.

    I remember being resistant to the idea of dropdown menus being added! I was young and foolish.

    Making LTS releases is simply the right thing to do. Corporations require stability and long term support. LTS versions will make it far more likely that they will adopt Blender. That will mean more money and minds for development. It is an excellent move.

    To me the version numbering scheme is arbitrary, but I think the proposed versioning will make Blender more marketable/palatable to the uninitiated.

    Much like myself, Blender is finally growing up;)

    As a developer, I have never found the time to contribute code. That is regrettable. I have grown tired of writing software and am transitioning to manufacturing. I can’t bring myself to switch to CAD/Solid Modeling software, when I know I can easily make my designs with Blender. Perhaps, I’ll find time to contribute a CAD/CAM add-on to aid myself and anyone else crazy enough to model mechanical parts in Blender.

  88. video editing more tools for blender sir…… i like blender………………………….

  1. Leave a Reply

    Your email address will not be published. Required fields are marked *

     

share this story on