The lifespan of Backdrop 1.x has been extended several times as the lifespan of Drupal 7 has been extended. Initially, our goal was for Backdrop 2.x to be released at least 2 years after the end of Drupal 7 support. Our hope was to give Drupal 7 site owners the time they need to both move to Backdrop, and prepare for the first Backdrop major version upgrade.
With the most recent extensions of the Drupal 7 deadline, however, the Backdrop 2.x release date has not been extended. Our idea of what Backdrop 2.x could be has shifted throughout the lifespan of Backdrop. We've been able to introduce countless new features as well as API changes in ways that have been backwards-compatible. Now that we have the experience, we believe that we can keep our commitment to backwards-compatibility across major versions as well.
With no API breaks, what's the difference between minor versions and major versions of Backdrop CMS?
First and foremost, we have been marking swaths of code as deprecated throughout the 1.x lifecycle. We would like the opportunity to remove this code from core in order to decrease our technical debt.
Additionally, there have been a handful of things that we have postponed changing in Backdrop core, even though they are not technically API changes. We have pushed these changes to 2.x because we were concerned they could affect live websites, or could be disruptive to the community. This includes core code changes like HTML and CSS, as well as process changes such as how we number releases for contrib projects.
It would be nice to have a dedicated release where we could make these kinds of changes. Each change will be well documented with clear steps for what to do if your site is affected (as well as as explanation as to why the change was made).
On February 29th, 2024, we devoted our weekly developer meeting to a discussion on previously-mentioned ideas.
Summary of Feb 29th meeting
This discussion gave us a general idea of what we'd like to do with 2.x. The decisions reached are in no way final. Many of these things will need to be voted on and approved by the PMC, but more importantly, we'd like to hear feedback from the larger Backdrop community at the Backdrop LIVE event in April of 2024.
Please keep in mind that our goal is to make the upgrade process from Backdrop 1.x to Backdrop 2.x as seamless as possible.
Should we change how we number versions?
No. We decided against 2 potential numbering changes:
For core: We discussed dropping the 1 at the beginning, and releasing the next version as (for example) "Backdrop version 28" (similar to how browsers now manage their versions). People overwhelmingly preferred having major releases where they could expect more serious changes, versus releases where they could be sure no changes would be breaking.
For contrib: We discussed dropping the 1.x- at the beginning of release numbers similar to Drupal, leaving only the semantic versioning. This would allow a specific version of a module to work for both Backdrop 1.x and Backdrop 2.x. We decided this might be a lot of work for our contributors, and we could instead change the way core works to allow Backdrop 2.x to run any release with the 1.x prefix.
Should we remove the drupal compatibility layer?
No. There was a strong consensus that the Drupal compatibility layer should remain.
We expect that there will still be sites moving from Drupal to Backdrop 2.x, and keeping the compatibility layer in will ease that transition. We discussed the possibility of disabling the feature by default for new installs starting with 2.x, and moving it to contrib on 3.x for people still moving off Drupal 7.
Should we remove other @deprecated functions, methods, and parameters?
Yes. Each major version will still be a milestone where we get to remove the code that has been marked as deprecated throughout the previous major version release cycle.
Are there other old things that should be removed?
Yes, below is an incomplete list of things we hope to remove in Backdrop 2.x, but there may be others.
- Support for PHP 5 (and maybe also 7, depending on release date)
- B/C instances of "master/slave" and "blacklist/whitelist" terminology
- The core Bartik theme, and the Simmons layout (should be marked deprecated in 1.x?)
- PHP-based file uploading and progress indicator (should be marked deprecated in 1.x?)
- jQuery 1.x (already replaced by 3.x in new installs)
- CKeditor4 (already replaced by CKE5 in new installs)
- Bootstrap4 Grid System (soon to be replaced with BS5?)
What should be included?
Having a shiny new 2.x release that only removes things is safe, but it's not going to be very exciting. Backdrop 2.x should also include enough new stuff that it's worth the effort of the upgrade.
New Features (as usual)
- We would of course like to include new features. Which ones are still TBD. It will depend what we are working on closer to 2.x release date. If we have some specially good ones, we could hold something for up to 1 release to get it into 2.x but we don't want to hold anything longer than that, because people still need new features throughout 1.x!
- We would also like to include new themes, perhaps for both the front-end and the back-end.
New Themes? How do we do that?
We discussed several ways to add new themes in ways that would be least intrusive for existing sites. Most importantly, new installs could default to the new themes, but the old themes would remain in core, with a slow phase-out period over the next 2 major releases.
- in 2.x, a new front-end theme (for example) could either be "Basis2025", or something completely different!
- In Backdrop 2.x, the original "Basis" theme could be marked as deprecated, and maybe also hidden from the themes page.
- In Backdrop 3.x, the original "Basis" could be moved to contrib, and "Basis2025" could be hidden and marked as deprecated, with a neew front-end theme something like "Basis 2027" (these names and dates are for example purposes only!)
What about any other front-end (css/html) breaking changes?
How to deal with changes that could disrupt the front-end styles and/or markup on existing sites has been an open discussion since the beginning of Backdrop. We've come up with several potential solutions:
- If we ever need to change front-end HTML or CSS, we create a public change record with the audience "Theme developer".
This will enable front-end developers to go through the list of changes to see if they will affect any given site, so they can verify every one before upgrading. - We don't change HTML or CSS in the theme, we replace the theme entirely.
- It was pointed out that it would be nice if we could also find a way to introduce CSS "fixes" between major versions, but no decision has been made on how to do that yet.
What dates should we aim for for Backdrop 2.x?
Undecided. target goals could be Jan 2025, Jan 2026, or Jan 2027.
Tools for upgrading to 2.x
We've already have a handful of resources for people who are upgrading to version 2.x of Backdrop, we'll collect a list of them here.
- Database log: Turn on this module and search for depreciation warnings. These will let you know if any of the code you are running is will be removed in 2.x, and needs to be updated before upgrading your site.
- Change records: All front end changes will be documented here, as well as the API changes
- TBD
What are your thoughts?
If you have opinions about what Backdrop 2.x should look like, please join us at the Backdrop LIVE event in April of 2024 to weigh in.