Note: Please join the discussion in the Drupal Slack channel to stay up to date.

As I started writing this post, I titled it “Towards a Versionless Drupal” — but as I thought about its content and what I wanted to say, I realized it wasn’t quite right. I want to see a bigger change in the Drupal community and in our product. Dropping “10.2” from the logo and brand is not enough, I think that we need to modify how we speak about Drupal as a whole.

A Survey of  Naming Conventions

It occurred to me that I should first make sure that as a community, we are indeed the only ones using a version number in our product’s name. I did the research and made a list of other content management systems out there. I looked at Wordpress, Joomla!, Ghost, Grav, Concrete, Umbraco, Sitecore, Wagtail, Hubspot CMS… and I couldn’t find any that used a version number in their name. Even TYPO3 is on version 11, 12 and 13, but you would never know it from the name. The “3” is a nice branding thing, not the version. (Let me know if I missed an obvious one?)

Why is “10.2” front and center on the drupal.org home page? I expect it has something to do with that-which-shall-no-be-named *ahem* Drupal 7 *ahem* and the very hard work we’ve done over the many years to prove to everyone—ourselves included—that we’ve grown up. Which we have! There is less technical debt in our codebase. We’re following numerous best practices, like using Symfony’s EOL dates. Our product is tighter, has more test coverage, more documentation. Let’s celebrate this! Why do we have to distinguish the latest version so explicitly?

Reflecting on Progress

We’ve made improvements that are leaps and bounds ahead of where we used to be. Sadly, the way we speak about our product retains the nuances of a past that is riddled with upgrades that required so! Much! Effort! And money! And the “upgrades” weren’t even upgrades in most cases… they were rebuilds that required major capital expenditure. Clients expected that they would have to fork over an arm and a leg just to have that major version number change. 

This is no longer true! We have successfully eliminated the need for organizations to leave Drupal because “it’s cheaper to just rebuild it in Wordpress than upgrade from 8 to 9 or from 9 to 10.” We’ve made it easier for our clients to spend less on major upgrades, we should be proud!

Drupal 10 releases have been on schedule, as planned, without issue. Upgrades have been painless, for the most part. We expect this to continue through all upcoming versions... and it is likely to continue to be easier and easier. This is what we have been aiming for all along—stability and predictability—clients love that. Anyone entering the Drupal ecosystem at this point will think this is normal. Success!

“But what about Drupal 7, Ivan?” — I have thoughts, keep reading.

Changing Perceptions

So, if it doesn’t cost the client extra for a major version update, and clients don’t really care about anything other than having the latest, most secure version… why do we continue to use a version number in our marketing? Why? I think it’s vestige of the past.

Consider the two major ways you use software — via the cloud and locally on a device. The lines have become more blurred with app stores making downloaded files easily updatable, but there is still a distinction between “apps on my device” and “apps on the web.” I asked Google Gemini to help me make a list of the main differences, then I edited and rewrote them for clarity. Here they are:

Table of differences between Apps and Web see Google Sheet for full data: https://docs.google.com/spreadsheets/d/e/2PACX-1vReDwbO_-6obD0V-Zi7N8gVUpgi-EbqcpQQsgSZZY4o07NUJn-HMMPnDEIYqk1UN5km-7VyDyVKIYmW/pubhtml

There are similarities here to how we talk and think about Drupal, i.e. if you use and maintain it for yourself versus if you provide it as a service to clients. Here’s the table I rewrote, based on additional work Gemini did for us that uses the same rows:

Table of diffs between Drupal DIY and Supported also at https://docs.google.com/spreadsheets/d/e/2PACX-1vReDwbO_-6obD0V-Zi7N8gVUpgi-EbqcpQQsgSZZY4o07NUJn-HMMPnDEIYqk1UN5km-7VyDyVKIYmW/pubhtml

The table entries are essentially the same: when you think of Drupal as a service that clients buy from members of our community, then you can easily draw the line to Drupal behaving just like a SAAS. And when you consider downloading and maintaining your own Drupal, then it behaves very much like downloaded software. One major difference between the two modes of use — version numbers! People don’t care about version numbers when it’s not their problem, but they sure do when it’s on their device and they’re maintaining it.

There are two rows that deserve special mention: Software Updates and Upgrades. I truly believe that we live in a world right now that any future releases of Drupal allow us to confidently say to our clients that their site is “always on the latest version” and “upgrades to new versions happen automatically.” We could not have said this with versions 8 or 9, but now... I think we can!

What About the Code?

I am by no means suggesting that we abandon semantic versioning, our release schedule, major feature builds and additions, or anything that would jeopardize our incredibly valuable process. No! We need to invest in this even more than we ever have. We need to make sure it is even easier in the future to do continuous, rolling updates to our product. We can only achieve this using a tried and tested process that we have mastered and continue to evolve. Keep doing releases regularly, keep versioning things so developers know where we are and where we are going, but please, please, please just say Drupal.

“OK, but what about Drupal 7?” — not yet, I am getting there.

A Community Call to Action

Dropping the version number from our lexicon requires a major paradigm shift. It requires a nuance that I believe we are all capable of. We are smart, progressive, inclusive, and empathetic as a community. We wish for any user that comes into contact with Drupal to have a delightful experience. Some of that experience is in the UI, some in the accessibility, some in the functionality. For someone new to Drupal, it’s also about how we speak about Drupal. Providing clarity and not confusion. Being curious and not judgmental. Simplifying our message. Let’s change how we speak about Drupal.

What if we

  • start calling it “Drupal” — just say Drupal
  • stop using the version number in our discourse
  • continue to invest in our operational best practices
  • accept the Drupal Association’s date for Drupal 7’s EOL
  • realize that this date will not prevent Drupal 7 sites from existing
  • embrace HeroDevs’ Never Ending Support of Drupal 7: it’s not going anywhere
  • rebrand “Drupal 7” as “Legacy Drupal” — not “Drupal Legacy” or “Drupal Classic” or anything that starts with “Drupal” and has a number in it. I believe this nuance to be important

How would this change our community? Our product? What effects would it have that I haven’t thought about yet? What will making this change do to adoption? Contribution? So many questions.

What do you think? 

 

We have a newsletter called Read Things That Matter — if you enjoyed this post, you might like being a subscriber.