This isn’t going to happen, and that’s a good thing - not a bad thing
Let me explain:
We create a theme API so that people can build on top of Ghost and create their own sites. This is one of the single best things about Open Source software, you get to customise it and create your own stuff. It comes with a pretty big drawback though:
Once we build part of an API and people start using it… we can no longer change it, or their site would break. So if it turns out that the first iteration of a feature didn’t quite hit the mark, or we really screwed up a naming convention in a particular helper, we end up with a hard decision to make. Do we…
A.) Leave it alone, close our eyes, and pray nobody notices. Create extra documentation to help people navigate their way through technical debt and architectural decisions which make no sense?
B.) Fix it. But break compatibility.
This challenge is not unique to Ghost. It applies to every distributed piece of software anywhere in the world, from your browser to your operating system.
The most sensible approach, which is what we follow, is to try to break things as rarely as possible. All new versions of Ghost are backwards compatible, with the exception of major versions (eg. 1.0 / 2.0 / 3.0). When we make a major version bump, that’s the time to retire old features from the codebase and break compatibility.
To be clear, there is nothing sudden about features being deprecated. When we deprecate features months (sometimes years) in advance of them actually being removed from core, and the messaging around what will break, how it will break, and how to fix it - is always extremely clear.
It’s important to understand that making major version bumps regularly is critical to keeping software fresh, usable, and fast.
- If you make breaking too often, nobody updates their software anymore (Rare)
- If you make breaking changes too rarely, the migration path becomes impossible (Drupal)
- If you never make breaking changes, the software becomes dated, confusing, slow and bloated (WordPress)
Our philosophy is to group breaking changes together and to release them when necessary at a cadence which is acceptable and with a migration path which is approachable. That’s how we do things.
Breaking changes and deprecation of old, poorly designed features is completely intentional. That’s how we keep the software evolving and improving.
It’s no different to how developers need to update their apps whenever there’s a major new version of iOS, Android, MacOS, or Windows. This is a sensible way to do software. Unlimited backwards compatibility is not.
It would be great to get old themes updated if you think you can help some of them, submit a pull request! Unfortunately there’s no reliable way to fix old themes automatically, but you can always check on theme compatibility using https://gscan.ghost.org