February 2023 update: the release schedule has been restructured.
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
agree on starting with 2.83lts to work on skills that would be needed in the future.
Hi ! I am 3ds max user But i really love to work in blender also but i am 3ds max using from last 15 years and new in blender so naturally some tools get compared with each others.
I am working in blender i am facing some problems Like 3ds max has Copy , Instance , and Reffrence object Bledner has instance and copy option but not reffrence option which is quite usefull option .
Like that Lighting has some missing tools or May be i dont know but 3ds max has Place highlight on object and Include / exclude option is there this basic kind of tools in blender.
Thanks 👍🙏
Thanks for improving this Cool Software!
I think you should hold your hands up and say we made a mistake with the naming from now is 2.8 == 3.0 and 2.9 == 3.1 Everyone with get used to it (or get over it) and it will just become one of those funny historical blips that every one knows that 2.8 means the same as 3 and then the rest will be easy – keep to 3 until the next major change to the interface or functionality.
Maybe it would be a good idea to improve The Blender Internal Rendering Engine and convert it into an add-on?
Version numbering should reflect what the product is and not internal development methodology.
If you change the main version often, you just make it hard to find tutorials and courses for Blender. This is why I suggest that you stick to the main version for as long as the basic functionality is the same and it’s possible to learn and discuss about the program with the same main number.
For 2.8 you should have moved to 3.0. I guess that this mistake in clear without further argument. That said, you should stop all the feature development and take a few months to perfect the current version. Make all the CI/CD pipelines and regression tests for the future and release a fast and rock solid 3.0 LTS. It can then serve as a foundation for many hobbyists and professionals. All the 3.x versions can then have additional features but still share the solid 3.0 part.
4.0 should then follow the same covention. Stop-and-fix to perfect what you have, create a new and shiny set of tests and pipelines, and start adding features on top of 4.0.
This is not a web browser or network management system you’re developing so it has very different version numbering needs. There’s no need for frequent releases. Actually too frequent releases hurt modding community and tutorial developers really bad.
un amigo
Why use versioning numbers resembling semantic versioning when the information you wish to reflect is when the new version was released, not that a major feature was added that breaks backwards compatibility?
Use year.month instead – 2020.4 , 2020.8 , 2020.12 and bump up the third number if there is a bugfix – 2020.4.1
But if you are planning to push breaking changes every few years regularly by doing a deprecated cleanup then actual semantic version numbers make sense.
I also support the YYYY.MM[.X for must-release-now patches] versioning scheme.
The only reason to keep the old (or the proposed) versioning scheme (X.Y), is if major (big change) releases are indeed centered on X. If this is not gonna happen, then there is no reason for a major.minor. I mean even the name suggests its use: Major.minor.
Now about LTS. Definitely needed. Every serious project needs this.
If this happens once a year, it should be not so arbitrary (May and X.3), as people need to “relate” it with something waiting for it. Like “last release of the year” or “first release of the year” or “every .1” (meaning that every .0 will possibly introduce new bugs, even if it doesn’t).
You can easily tune this as you can decide which will be the first LTS (even you delay LTS for a release or two, the first time).
My .5.
:P
Totally agree. LTS releases for studios, catering the industry helping them in their projects. This improves the number of serious users. Non-LTS releases for 3D enthusiasts who are fascinated with 3D and associated technologies. Free-lancers, learners etc., Useful for testing new features and stabling the existing features. Good decision. Hope to see the usage graph grow up. Keep it up Ton.
If blender can combine the ability of CAD software too, then it’ll be the perfect choice. They should integrate CAD support. Fusion 360,Inventor and AutoCAD will be out of business If this happens.I hope blender 3 will have more tools than inventor and fusion 360.
I hope this happens in blender 3 as inventor and fusion 360 are paid softwares and that’s why blender will again come to the recue.
My BLENDER 2.8.3 falls out when in the finished scene I try to create a new object and then make the SCALE in the window …
anxiety intensifies
As if this conversation was not already long enough, here are my 2¢ :)
Since one of the major promises here is that every year a new LTS HAS to come out, I would have suggested that the first release of each year would be the yy.0 LTS by default, and the subsequent ones yy.v+1
Thus:
– 21.0 LTS (or simply 21 LTS or LTS 21… then patched into 21.0.1 LTS, etc.)
– 21.1
– 21.2
– …
– 22.0 LTS
– etc.
This way we would implicitly promise that, as the year ends, the next release has to be an LTS. It can come out in January as well as in April if it needs a bit more time, but it is what all the development is focussing on.
Additionally, this would suggest that the milestones are denoted by stability and commonality as core values. This would be in contrast with the experience of paid software that needs to flex a bunch of rushed sexy new features with each new release and then be patched a couple of times before becoming actually usable…
This way each year would start off with a new stable, solid, mature platform, to experiment with and be used as a foundation for new ideas and features.
Honestly, what I see in version numbering for 3.x and upwards is a bit weird to me. One of my opinion that works better for blender to me is:
1. Use x.0 (e.g, 3.0, 4.0, 5.0) for blender with very experimental releases (like any features that’s really takes a long time to make, put it there). This way blender can use this “bleeding-edge” or “prototype” version like one or two year ahead before it goes stable.
2. When it’s the time, release it three times a year, e.g, in 2021 we have 3.1, 3.2, and 3.3 LTS, then next 2022 we have 3.4, 3.5, 3.6 LTS, and the last 2023 we have 3.7, 3.8, 3.9 LTS. This completes at 3.9 and wraps again in next year at 4.1
I believe this is just my preference matter and Blender might have a reason to stick with four time releases a year.
blender has a big future ,you guys are doing great job
I think the release numbering as it is is just fine. Working on a fix on 2020.03 while it is May to be implemented in 2020.06 gets delayed and gets released as 2020.07 makes things too complicated. I just wonder is a 2 year support for LTS versions is enough. It would be better if they made conversion tools to upgrade or downgrade between LTS versions made designs.
Let’s say you own a virtual factory website with 3d products (concrete, metal, plastick, etc), where clients can use parts to construct things they want. The final construct becomes a product specific for that client that might order the part for several years. You can’t say to the client “Sorry”, our 3d modeling program doesn’t support products older than 2 years and you have to make it again with our latest version.
With every LTS release you want to upgrade all your work and you don’t want to do it one by one as that might a lot of time.
There’s an old saying, keep it simple.
I don’t think there’s any good reason to add the LTS naming convention, it just makes it more complicated and confusing, I’d like a Blender 2020.06.19 approach.
Just the simple date of release for mental comparison.
If a company is serious about using the product and wants the features the product offers they will need to step up and commit to it, they will learn about and use the product and if they require an LTS they probably make their employee’s sign NDA agreements just to use the product.
Cool! long term planning
Will there be a 32-bit support for the 3.0 or will it be still for published for the 64-bit system?
Funny that most of you know better than devs, which numbering system is better for the software they work on. “What he hell! Let’s change blender’s serial number to the one max or ubuntu has, because we are all to lazy to visit http://www.blender.org, to check current LTS release.”
Devs knows better what works for them.
Working with 3d text in blender is the bad and outdated since 10 years .
The remesh and convert process is pain in the eyes.
A near ten years old Forum post and a video how A ten years old cinema 4d handle this typ of workload with easy show how blender lacks fundamental path and 3d Text or Font feature and better build in remesh tools without to convert to paths or meshy thinks and wast hours for creatIng and controlling some simple 3d Text.
https://blenderartists.org/t/deformed-text-and-curve-based-shapes-render-terribly-will-this-be-broken-forever/557768/7.
I’m tired of fighting with the old blender 3d Font module that can t creat good Text Objects ot can t bring in office text controlling text font feature.
In blender 3d Text creatIng is only a toy .
Like the Video sayed ”Broken forever”
A Programm for the pro .for the bis Studios ..
Oh no Not with so outdated Tools …
Blenderartists Forum Show how 3d Text creatIng is a shame in blender wen you want a mesh for deformIng Animation.
Please fix IT but Not again 10 years ..
Could try vector graphics editor and import the shapes into Blender for further editing to finalization.
video editing more tools for blender sir…… i like blender………………………….
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.
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! :D
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
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.
The problem with this is you end up with a bunch or random plugins that are compatible while many others are not. The main interface code needs to support the backwards or forwards compatibility same as standard PC cases support ATX motherboards or the main power connectors on motherboard and power supply support eachother, or the PCI-E devices and slots are backwards compatible. Same with USB and AM4, etc…
I can’t wait😘😘😘😘😘😘
https://devblogs.nvidia.com/nvidia-ampere-architecture-in-depth/
https://devblogs.nvidia.com/cuda-11-features-revealed/
Please add Nvidia Ampere GPU support to Blender.
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.
Imagine Blender 5.0…
I even can’t wait 3.0
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.
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.
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.
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¢.
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 :-)
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
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.
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.
Whooah LTS just like Ubuntu. But it makes me confuse
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 =)
Everything about the new Blender is awesome and welcome! :)
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!
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.
Please avoid the ridiculous style of Chrome and Firefox versions.
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.
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.
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.
LTS is a good idea. Means there’s very little worry about cross contamination of versions. I approve.
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!
Should an LTS version be preceded by a Tracker Curfew?
[[https://code.blender.org/2019/12/tracker-curfew/]]
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).
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
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.
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.
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
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.
You could rely on steam for that purpose.
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!
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…
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…
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 !
THE MADNESS!!!
By Year 2030 well be at:
Mozilla v98234234234234546
Chrome v99456456345345353
GCC v99534573466675347
Clang v93554934593495394
Blender v935349534959349539459349593495934593495934…..
You forgot the LTS at the end of the blender version.
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 ;)
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 : )
Very good summary and proposals.
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 !
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.
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, …)
FIX:
4.7 -> 3.3.3 LTS and fix releases (3.3.4, 3.3.5, …)
+1
+1
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.
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.
A material editor for terrains is needed, there is an option ‘Material’ in the A.N.T.Landscape, but it is empty.
This feels like turning into subscription model, where each release is a point release….goodbye milestone releases, no more big hype.
LTS = great
but this jump every year to a new version feels wrong. A new version number should be more like a new generation
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
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
Undo is planned for 2.83.
OMG!!! This is amazing!!
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. ☹️
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.
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 !
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?
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.
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…
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.
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!
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.
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.
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.
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?
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.
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 👍
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.
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.
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.
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.
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.
Blender is going more and more towards the industry standards: regular releases, LTS and competing with others. Mantaflow fluid sim et al. Great job!
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.
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
I agree. Forget the yearly numbering idea. It’s a real nasty idea.
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 ^^
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!
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.
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.
Yup, I agree.
From the moment 2.8 came out, I was confused why 2.X series still exist.
2.8 was such an enormous update that it really needed to be called 3.0!
And that’s, in my opinion, the most logical scheme. 1.0, 2.0, 3.0, etc., should be the major versions with extremely notable changes, while everything in between should be reserved for bug fixes and similar.
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.
I think the versioning could be improved for the LTS versions so that you know that a certain version setup will always be an LTS version even it’s not written in text.
LTS for 2.8X is
* 2.80
* 2.81
* 2.82
* 2.83 LTS <-
LTS for 2.9X is
* 2.90
* 2.91
* 2.92
* 2.93 LTS <-
I would keep this style for 3.X. So it would start with
* 3.00
* 3.01
* 3.02
* 3.03 LTS <- (To be honest, I don't like the 3.00 though)
The next cycle would be
* 3.10
* 3.11
* 3.12
* 3.13 LTS <-
I think you get the idea: x.y3 is always the LTS version
Awesome thanks for the software cant wait to get back into working on it again.
YYYY.M makes much more sense
Debatable. For me, it’s easier to associate blender versions like 2.81 with certain milestones than 2021.3 and year version naming is as arbitrary as number one.
This. I totally agree.
So we these changes there will be no more big milestones since the versions jump will happen quickly?
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.
The introduction of new features in experimental releases will allow users to rate them. Thus, you can see what needs to be implemented in the LTS. It’s a good experience.
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.
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.
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?
Why not Blender YY.MM ?
For example “Blender 2020.2”
to be more precise, then YYYY.M
so 2020.1 Jan and 2020.1 Nov?
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 :)
I agree
Agree too, dont like Adobe 2020, Autodest 2020, too commercial taste.
agree
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? ;-)
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 :) ).
Big news! Can’t wait!
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
Hi every one!! Should I learn blender? What guys you recommend me as 3Ds Max VS Blender VS Cinema 3D, Which software is better?
Hello Wajid Ali,
The question of the best 3D program is a matter of taste.
If you want to work in a Hollywood movie studio, you will probably have a hard time getting past 3DsMax or Maya, as many studios use them.
With Maya, 3DsMax and others some Hollywood productions have been made.
But also Blender is getting more and more popular in Hollywood.
Blender is open source, financed by donations and offers everything you need to make a good movie.
The other software you mentioned is in some cases a little easier to learn and offers functions that are sometimes a little easier, but this software is also extremely expensive.
Conclusion:
I recommend to start with Blender.
I mean Blender is completely free and the download of less than 200 Megabyte doesn’t hurt at all. Just try Blender and if you want to buy another software, you can still do so.
If you have any questions, feel free to exchange your thoughts with others in one of the many Blender forums.
The biggest feature of Blender is the community behind the software. Blender is not only yours, it is ours, because every user can help to make Blender a little bit better, or not. Blender is freedom.
Tip:
it’s hard to get started, no matter if you use blender or Maya. You will need some time. Start small, follow a tutorial of your choice, or buy a book.
No 3D software is better what do you need to ask yourself is how much money do you want to spend because blender is free and just if not as powerful as the paid software
Yes, you should learn Blender. I believe all serious 3d artists should learn it. Eventually, studios will want to move to Blender to save on reoccurring costs. Not to mention it’s easier to use now.
They just need Cycles or another rendering engine, that will give you results like Octane or Vray. It gets close though. I love using it for pretty much everything.
They also need to update the painting system. It’s icky.
In order to prevent spam, comments are closed 7 days after the post is published. Feel free to continue the conversation on the forums.