They do small, frequent software updates, it's called minor and patch versions. But when you're making a tool for creative professionals you don't want to release major versions of the tool every year, because these professionals care more for consistency and using their current skillset more than shiny new features in the next version.
This especially true since this is a FOSS tool so there's no need to ship product bumps to sell units or anything like that. They can just release stuff when its ready.
Major version bumps with major features are still a great marketing tool; like this article making it to the HN frontpage. That attracts users and developers, both desirable for FOSS.
Except that we have releases of Adobe and Unity and things multiple times a year. Creatives value consistency but they also value ease of use. Improvements to UX and workflow should be allowed to break the mold of "don't touch it if it works". What they don't do is dictate the release cycle. Many patches end up in committee to be pooled together (or paywalled) into a vX.N.0 patch released when the business decides to.
Everyplace I've worked that's used Unity has locked into a version at the start, and only upgraded (other than minor versions/bug fixes) between projects. New projects today would use last years version.
Adobe is less an issue because the new version of Photoshop isn't going to break your PSD.
> Everyplace I've worked that's used Unity has locked into a version at the start, and only upgraded (other than minor versions/bug fixes) between projects.
Having used Unity for a few years, this feels like the only sane approach. It might sometimes be possible to update a project or even follow the best practices with package updates, but in practice there's just too much brittle stuff that breaks (e.g. all of the materials in a project breaking and becoming invisible or other weird things, like scripts suddenly throwing plenty of runtime exceptions).
Just pin to whatever the latest LTS version is and then conservatively update packages as necessary.
Thankfully most games aren't too integrated with network solutions and don't have to worry about security related topics, like how a typical .NET or Spring Boot webapp would have to.
Their users. Game engines are big and complex and the foundation of building a big and complex product. You can't have your foundation introducing fundamental changes on a regular, unpredictable basis.
Releasing big versions means your game can use version X.Y with only bugfixes to the engine added as updates and you don't have to make fundamental changes when the game engine changes.
A lot of games are fragile, and have poor or no test coverage. So if the engine changes, it can break or have all sorts of unforeseen consequences. So you want to be building in an engine that isn't changing.
They do, it's called the master GitHub branch. But generally if you're shipping something that doesn't get updated as often (you don't want to update via Google Play or Steam as often as a website would) you'd like a little stability...
