Change the Blender Master to be a stable version
Issue
Blender has a branch for 2.83 LTS, a branch for 2.9, and then does other alpha and beta development in the Master, eg, 2.91 Alpha is the assumed Master.
This causes unstable code and development the de-facto root and source for development - as it's the Blender Master - causing more work when doing new branches, addons and forks for opensource development.
Since the master code is experimental and unstable, the workflow with the master sometimes has un-predicatable issues caused by refactoring, new features, and more which causes issues in general development that might not be due to your branch or code - and thus it is not multi-developer friendly due to it's inherent instablility out of your control.
Solution
- Make the LTS branch release the Master (2.83 LTS)
OR
- Make the latest public stable release (2.90) the Master
And then do any Alpha and Beta development (2.91, etc) of any future or current experimental build in a separate branch, then merge it in when this branch is stable for launch and public release.
TLDR: Follow typical software development standards for stability:
Master = stable public release
Branch = new features and bug fixes for future releases
Use a Pull Request system = the branch has been tested and is stable by the developer and testers, now it is ready to be merged to Master and reviewed
Merge = the now stable branch is merged into Master, now we can release a stable distributable of the Master to the public or work with new addons/branches/forks with a stable foundation.
Reason
As the code is GPL and open - you can fork and branch Blender for your needs. Typical development work would imply that you fork from the master, branch from the master, and use the master for development - even test in the master - then you also need to code and repeat and test again to do the same for the other branches (where it's not clear which is priority and future proof) With that experience, you struggle through bugs and issues the master has due to experimental development that most likely has nothing to do with your own development. The Master should be the public stable release, and the de-facto point of reference for addons, general development and opensource development, and also be a solid foundation to fork and/or branch from.
Right now in the general development industry, typically for large development teams, a master is released as the stable version for the public, and any future development is done in branches then merged in when all its commits are tested and proven stable. Then once the development branch has been merged to master - with all it's new and experimental features and code - the master accepts the pull request after revision and then can release a point update to the public, and thus be more stable from launch - and also it will be stable enough for any other new fork, new branch or any other GPL distributable and development for that matter.
But Blender, for some reason, releases a branch to the public, and continues to do future and experimental development in a central Master. This is great and agile for small development teams, but it is not great for opensource development with other users who do and have access to the repository - which can be in the tens to hundreds of developers. It also is not great when you have multiple developers working on the same documents at the same time in the master ultimately. It is a recipe for future disaster and more bugs in the long term - as we are now seeing in new 2.91 builds where Eevee looses transparency in renders, the UI glitches on startup, and more. Any fork or branch inherits these sometimes showstopping issues and any new development is slown down due to the unstable master.
This has, in turn, caused frustration for developers, voice publically and also known privately - decreasing the attractiveness to onboard developers - and also decreasing the desire to create new branches for future features (since you'd be working from unstable alpha code instead of a stable master, which is subject to change almost daily) Your work will have to double or even triple as you then have to also develop for a different set of branches, merge in code from the master often hopeing for fixes and risk conflicting code over and over again (weekly or daily) due to the Blender Foundations choice to do feature development in the Master..
Also, If you are to also maintain development for branches that have public priority - if that is a requirement - which branch? The Functions Nodes branch? The old Game Engine branch? It's not straight forward nor organized. Development this way is tedious, unstable and not open for larger teams and stable development with other parties.
Summary:
LTS is a good idea, but also make the Blender Master source code a stable version - and keep the refactoring and new feature development along with their testing and bugs separate, so that development with other branches and forks be harmonious and efficient.
16 Comments
I think this request is useless, Blender developer already use one well know and tested workflow to develop Blender. AFAIK Blender core devs have already fully and at longer discussed and changed this workflow and IMHO it is working very well. Why ask or promote changes if not touch users life and not touch too much addon developers? I think actual Blender development workflow is very nice and smooth. All new (more) unstable code in
masterto be fixed and stabilized for the release (now 2.91alpha). One tag for latest stable release (each 3 months), now 2.90.0. One other tag to stable LTS version (each 2 years), now 2.83.6. Addon developers not need know other if how to compile Blender using tags and how changes pre-compiled libs to have one older Blender working* @NiCapp * there's a reason so many other communities use git-flow or some other similar option. "We've always done it this way" is no real reason. If Blender operated in a vacuum, the way they're doing it would be reasonably OK even if still not best practice, but there are third-party projects that implement the Blender codebase. Having all merges directly on master makes it impossible to easily get the latest upstream release at any given time (especially if tagging is inconsistent or has changed at some point - e.g. a switch to semver).
* @NiCapp * This request is for developers beyond addons. And just to reiterate, developers have pulled even official addons from Blender due to the requirement stated: that he needs to develop for multiple branches instead of only the stable public master. This is for any developer who wants to work from a stable sourcecode, knowing that their work will just work without any alpha or beta development breaking things the third party developer is trying to do. That is the common practice, a stable master - and this should have been the expectation with LTS in the backend.
* @seanr * AFAIK Blender is
notother communities. "We've always done it this way" was changed after most one year of discussion (Aug 2018 - Sep 2019) form Blender core developers (who use and manage Blender developer workflow) to make predictable release date and more smooth workflow from one stable release to next. I think Blender not cure too much to external fork, you can ask to external developers to follow what Blender already do and how is made. AFAIK Blender tag is consistent and use alpha code to make changes over is (IMHO) not one problem of Blender developers. i Think you miss something as code.blender.org/2019/10/blender-release-cycle/ , code.blender.org/2020/02/release-planning-2020-2025/ , code.blender.org/2020/05/long-term-support-pilot/ , code.blender.org/2020/06/modules-roadmap-june-2020/ and just now i not find master task and relative discussions on these changes in developer.blender.orgp.s. i not related with Blender in any way, all i write is is one part of info that Blender had publicly released
TL:TR IMO Blender developer not have problem with this already discussed workflow, i am pretty sure this not will change in near future in easy way
* @NiCapp * Just to be clear, the plan (experiment anyways) is to have an LTS tag every year. Each LTS lasts 2 years though.
* @Dalai Felinto * I know, this, you write or review documents i link
* @NiCapp * I saw that you linked the docs, but since you wrote "One other tag to stable LTS version (each 2 years)" I wanted to be sure everyone else doesn't misread that
* @Dalai Felinto * well this was wrong, other can read that LTS is released each 2 years instead LTS will be release
eachyear, my bad. Thank you for correct this errorThis might need to be posted directly in their issue queue as well, not sure how actively they check here, but this is a big deal. The obvious solution for this would be to adopt a git-flow workflow like this:
Put simply, current master becomes develop, and new master only receives tags off of developer either via release branches or hotfixes - never direct commits.
* @seanr * I totally agree here. I guess I can make this an issue in the tracker directly... or in the Dev forums?
* @seanr *
This is already quite similar to what the Blender development team is doing:
The main difference I can see (correct me if I'm wrong) is that the severe bug fixes happen straight in master, and then are backported to LTS (or a corrective release).
If things go accordingly to plans, there will be a new LTS every year where critical bug fixes are ported for 2 years in total.
* @Dalai Felinto * In this case, point 2 here is where things break. You are doing development in master, which in the front end is hidden, great.. but this is a backend issue where any developer working with the respository will get and see as plain as day.
And then there is also point 3, the fact that.. if I want to futureproof my development, do I branch the branch of the master (LTS or 2.9.0) soon to be 2 years old now in under a year, or less, or do I develop from a branch that will ultimately be absorbed and no-longer exist in the future as soon as the master is branched to another public distributable with completely different code, even API changes? Or do I branch from a bugfix based unstable master that is a no point based release in general, because it is the development build - always evolving, unstable and with bugs that aren't from my own development?
This proposal (and the others here) are "technically" interesting for sure. In my opinion, however, they neglect something essential: How to drive testing to branches? Why are bugs being introduced in Blender and not spotted soon enough?
Centralizing the main development in master helps to drive more traffic to the latest development. The other thing that is on the agenda is to try more and more to have the Beta releases stress tested (to prevent critical issues reported only after a stable release is out.
I would like to welcome anyone technically inclined to try to map when the issues are being introduced. For example, the bug fixes that were ported to the LTS, or even the 2.90.1. Were they caused by features in bcon1? bcon3? Regressions from fixes? This is a lot of data to process (e.g., LTS has over 140 fixes ported over). But it would give Blender valuable information on where to improve testing and Q&A.
If that sparks anyone interest, you can talk to me (dfelinto on blender.chat ) and I would be glad to look at the findings. (full disclaimer: this is already in my agenda, but I've been prioritizing other tasks)
* @Dalai Felinto * To drive testing to branches would be the same way you distribute branches right now, just like you have an LTS branch(tag) and distributable, you have a 2.9 branch and distributable, and the only branch you aren't distributing is the developer branch which doesn't exist, because it's the master. I would suggest to keep the master the stable LTS release, the master release, the public release, the opensource stable root that any third party developer could use for conflict free development to merge back to master later into the future- and then distribute the experimental builds from the a new "developer" branch and merge to master after quality assurance has been tested and fixed. This allows for any developer to fork and branch the master without inheriting any development woes and work in progress. On the front end, nothing changes. On the back end, things are cleaner, more compartmentalized, and easier for conflict free collaboration. It's a simple change, and a lot tidier - workflow is no different. A core developer would stop committing to master, and then commit to the developer branch. A developer lead would then review pull requests to master checking merging conflict (potential bugs), then after every issue has been ironed out, a periodic merge of development branches based on the release cycles of LTS or point based releases would happen. It's gitflow the way it should be.
Concerning the issues that get introduced in the pipeline - they are inherent to development: code refactoring in sculpting, in the drawing of the UI, of integrating Vulkan, the refactoring of Eevee just this month, refactoring of mesh drawing and dependency graph updates this year, etc - all of this has caused hard crashes and showstoppers, even multiple bugs reported, some fixed - our forked master merging in the Blender master weekly makes our daily artistic studio work unstable, meaning double work to the devs to make sure development is not a Blender bug, nor our bug, I would assume anyone doing a branch of blender would have to periodically do the same, slowing down development. This is an issue because we can't afford to merge in a stable branch of the master AND the official master and then cross check the code of both repositories and our own to make sure it's not conflicting, because any step away as a branch from the master will cause incompatible code over time with our own branches now two steps away from the present and future, thus increasing bugs over time and more work to avoid conflicting code. A merge from any other development branch back to a "development" master after being branched from a stable branch will be chaos.. You can't just branch a branch to make a stable build with new development when the future is and will always be the master.
We've been working from Blender master merging into a fork weekly for years now. From experience, these issues have been presenting itself months before 2.9 even has been released, happens during the Bcon's, and before. If a team of third party developers were to optimize time and development, it would be best to minimize the branching and code deviation from a solid core and allow others to work directly from a stable master in mind: any development should always be in branches which can be reviewed, paused, and tested before going to a master so that conflicts can be foreseen with each pull request to master. And better yet, work with development branches based on module teams or even per developer - then you have more power to control the gateway for potential bugs and conflicting code with the supervisors or directors to make sure code doesn't destabilize the master.
Keep the master stable. It will drop bugs in the long run.
Thanks for reading, really appreciate it.
Wasn't one of the stated reasons for the Epic Mega-grant to improve Blender's development processes/practices? This proposal seems right in line with that. Doing development in Master is bad practice (like how testing in a live environment is bad practice).
Fully agree with this. I feel like Blender has become less stable in the non-LTS versions since 2.83 was released. Random crashes are seriously frustrating and can be costly. I'm seriously considering going back to the LTS release and foregoing the benefits of the "stable" master releases.