[Discussion] Recommendation for dropping version numbers for external marketing of Drupal

I think this is great! I reached out to @baddysonja → to ask advice on who to speak with and she recommended Promote Drupal.

https://www.drupal.org/community/promote-drupal →
https://www.drupal.org/community/agency-marketing/promotedrupal →

Worth adding the origination point of this conversation https://youtu.be/HJgmt4iO6Jg?si=WNayABZr2Kq8oceC&t=4046

I agree with this fully and would love to talk more about it.

OMG yes!! I said this many times when I was at the DA, I’m afraid to deaf ears.
Increasing the major version number doesn’t bring new features, they come in the minor releases. All that a major release brings is the dropping of outdated code and dependencies.
Celebrate the minor releases, not the major ones. In all things of life.

I have changed this issues project from 'Drupal core' to 'Drupal core ideas'.

Updated issue project: I moved this from the "Drupal core" project to the "Drupal core ideas" project.

Removing version numbers could get a little weird, they do have meaning that lands in the non-technical realm.

My developer says we need to upgrade to drupal 11 because drupal 10 is end of life, and he's sent a promotional video about Drupal 11 to help convince the director who doesn't understand the situation.

I like this for marketing, a lot.

We've put a lot of pain and effort into making keeping current an achievable goal for normal operation, and we should lead with that. If someone is owning and maintaining Drupal the version and updates may be more relevant to them. And perhaps they'll be making choices about when they time update. But if someone is buying into Drupal now imo they should be buying into the idea that they will keeping current with the latest stable release.

I don't see major releases having a major cost impact on clients. I see lack of upkeep having a major cost impact. I'd also like to send an end to the term "end of life" because outside of the community, it doesn't mean what you think it means. : )

Lack of upkeep is terrible, but incredibly common. If you don’t implement the new functionality as it becomes available (which is even harder to sell to clients), the major version upgrades still take a decent chunk of time and are not as painless as they should be. Versionless marketing may make it more difficult to explain this to clients.

Other than that, I do like the simplicity

I just want to clarify something that I missed the first thoughs. I think this is more about EXTERNAL marketing. To people that do not already have a contract and do not already have a Drupal site and may not have heard about Drupal.

So the discussion about major version updates and maintenance would still happen, but when communicating or sharing things more externally it's just Drupal. Not Drupal 10.2 or Drupal 11 etc.

I just want to clarify something that I missed the first thoughs. I think this is more about EXTERNAL marketing. To people that do not already have a contract and do not already have a Drupal site and may not have heard about Drupal.

I think I'm on board with that, but it would help to have specific examples of where we would see the impact of this change?

And further, are there specific examples of other software, open-source or commercial, that benefitted from doing what is proposed here? If so, how did they benefit? Is the benefit measurable?

I'll let other's chime in on Aaron's question, but for @cilefen, I'm not sure about positive effects, others may have examples. But the Drupal community has direct counter examples of why the version advertisement was a pain point to this community.

Drupal 8 was pushed so early and so loudly that many organizations delayed building new sites until Drupal 8 came out. This caused multiple year's of delay for some projects. If Drupal had been marketed as Drupal alone then many of those organizations would have likely adopted Drupal in 7 and been updated in the intervening years.

Obviously Drupal 7 to 8 were some special circumstances, but if external marketing was more Drupal vs version focused it may have helped, and I understand this was one of the points of genesis for opening this issue.

I am not a fan of this idea as it may damage Drupal's perspective and ecosystem.

Quick example. Hypothetic customer obtained his Drupal 7 site. Yes, it is still working. That's the only benefit for the customer. What are the problems?

- no way to extend the system as all is outdated
- not so many developers will be happy to work with legacy and obsolete code
- the system may be insecure

Practically it is the site without the future.

If the customer is not aware of the problems above he will never invest in fixing them. And as a result, he will blame Drupal. Not just the outdated Drupal version and lack of care, but Drupal.

Here's my full thought process https://ten7.com/blog/post/just-say-drupal

I like the notion of referring to Drupal without the version number in sales and marketing situations. When we're discussing Drupal 7, I like the idea of saying "legacy Drupal." In a situation where there might be confusion between Drupal 7 and Drupal 8, 9, 10, and 11, why not follow the convention of saying "legacy" or "modern" to differentiate? I would agree that most clients don't care about version numbers. I agree with Ivan's observation that no one uses version numbers when discussing Wordpress, or any other CMS.

I understand the goal of this idea - but I think it could lead to more confused frustration with the general public.

There is unfortunately a LOT of people who I encounter who say "oh man, Drupal SUCKS"

Not understanding that they're experience in Drupal 6 is ... well, dated...

I think theres value in some how making sure people know this is the NEW Drupal, and that even in the last year there have been significant improvements in "out of the box" user experience then there was in Drupal 9... and Drupal 8.

This makes a lot of sense for the external communication, and this is also how I have pitched Drupal since 8, without maybe having reflected a lot on it.

There are several sides to pitching Drupal, and one quite rare one is that some clients are tormented by an earlier 7 to 8 upgrade. For these I simply explain that 7 to 8 was a rewrite, not an update, and this is not how we do it now. However, this is actually in the past, and for the majority of prospective new clients / users it is simply not relevant, and ought not to be a part of the discussion.

For new clients we present an evergreen model. You pay a monthly fee and you are always on the latest version. If that is called 9.3, 10.4 or 11 is not relevant. Much like I myself don't know which version number the browser I'm using to write this in has, except that it is the latest.

The other side of this is that pitching version numbers also gives an expectation that you get something new and fancy when you bump version, while this is seldom true for the editors and end users. It also gives the impression that innovation is bound to version numbers, which is equally not true.

Most visible innovation / change for clients in my experience happen when introducing for instance Gin, Gutenberg, Paragraphs ecosystem, Layout Builder ecosystem, Webform, or simply new and smarter ways of building their functionality, or improvements to design / theme. And all this goes async to core version numbers.

I think the last two comments raise a great point. The "Fear of Drupal" or "Drupal Sucks" mindset is out there. I couldn't agree more, matter of fact I ran into it just a few months ago.

However, I don't think the above mindsets have to do with us saying "Drupal" vs "Drupal 10". More so, I think they have to do with communicating and informing those people on how the current version of Drupal is better.

As an example, the above person from months ago had not used Drupal since Drupal 7 and the team that built the original Drupal 7 site didn't have a great governance model in place. This lead to "wild west" Drupal and something that become hard to use and unmaintainable. After having a conversation with this person and discussing their concerns I was able to inform them that Drupal had improved greatly. I also was able to communicate that Drupal's upgrade path going forward would not require rebuilds and if used with a headless front-end could provide more benefit while easing concerns.

I think the above comments around The "Fear of Drupal" and "Drupal Sucks" apply no matter of if we say "Drupal 10" vs "Drupal. I honestly think it comes down to communicating the improvements and having a conversations when these scenarios arise. I don't think keeping the version number in marketing and conversations helps this situation because at the end of the day does someone who thinks "Drupal Sucks" really care if we say "Drupal 7" vs "Drupal 10" vs "Drupal"? Quick answer no, they stopped listening when you said Drupal :-)

We are a wonderful, open, and accepting community of passionate people. We should standardize on "Drupal" and be excited for the conversations it will foster. "Have you thought about using Drupal" - "Drupal Sucks" - "Well, whens the last time you used it? Why do you feel this way" greatness will ensue. All without a version number.

Updated main issue to list out the resources and other sources of information to support this post. Will be doing a Lightning Talk at Boston Drupal Meetup about this. Interested in others thoughts/opinions on this.

Fixed TEN7 branding

I agree, we should just call it "Drupal" from now on externally. Upgrading from Drupal 7 to Drupal 8 was a big task, as we all know. But going from Drupal 10 to 11 to 12, and so on will be much easier. In fact, I just offered an update and service agreement to a client, and included major upgrades, from 10 to 11 to 12, etc. just the same as I previously did minor updates, for example from Drupal 7.88 to 7.89, or Drupal 10.1 to 10.2. I used to not include major version upgrades, since it historically could include a lot of changes and work.

But since the changes between major versions are now relatively small, I include major updates in a standard update service agreement, seeing them as on the same level as minor updates.

So let's just call it "Drupal" from now on, and not mention the version.

Wow, didn't know this was already being discussed 10 years ago!

I think this would also benefit from a client perspective. As like said before, many of our clients still think a major drupal core upgrade (like 7 -> 8) is a loooot of work and would cost them a looot of money. Which is these days quite the opposite!

I also support this idea!

If you look at documentation for say the Symfony cache component, you end up on https://symfony.com/doc/current/cache.html which is 'current' and then a dropdown by the actual versions. But the version is de-emphasised unless you really need it.

api.drupal.org on the other hand doesn't have an equivalent of 'current', maybe when 11.x turns into 'main' that might work, but at the moment you get 11.x
10.3.x
9.5.x
8.9.x
7.x

Two out of five branches are unsupported. I opened 📌 Remove Drupal 8.9.x and Drupal 9.5.x from api.drupal.org and redirect to 10.3.x or 11.x Active .

This feels so totally uncontroversial to me :)

We have effectively been doing this with our clients probably since 8->9. We still inform them when we're doing an upgrade because it is work that we have to do and testing that they have to do, but most of our clients could not tell you what version of Drupal they are on. (Those that came to Drupal at 8 or above, if they didn't migrate from 7, probably *never* knew what version they were on.) We also no longer specify the version we will use in proposals. So we have been speaking in terms of 'just say Drupal' for many years now.

To the 'what do others do' question, we use Laravel as well and from what I can tell, it is similar to Symfony where you can find it if you want but it's not prominent at all. The install docs do not mention v11 at all, the only place you can find it is in the URL.

I also feel that folks who have pre-existing fears or impressions of Drupal are probably not the audience for this change, and likely any meaningful discussion with those people would require some explanation of version. So that's not really what we're talking about here.

(Of course, we also still will need to promote that new versions are out, but that's for developers who are following along, not new users or evaluators. Again it's a different audience.)