With any software development, you have to take into consideration your technical dependencies. This is no different in WordPress plugin development. The caveat may be that in an ecosystem with 40-50% adoption and over 50,000 plugins in the directory, how can this process be more of a team effort?
The first release candidate for WordPress 5.7 will be released 23 Feb. WordPress 5.7 will launch 14 calendar days later on 9 Mar 2017.
Update 30 Mar 21
The preplanning for WordPress 5.8 has a timetable and there is now a 21 day RC window (June 29 – July 20). WordPress 5.8 drops 20 July 21.
Update 13 Mar 2021
The roadmap has been updated this week. WordPress 5.8 will be released in July and 5.9 in December. So, we’ll only have three WordPress Core Updates this calendar year. Yes, breathe a collective sigh of relief. Thank you, Josepha, for listening to the community.
“Here are a few things that might make this communication more difficult. If you can think of other communication challenges (or solutions to the ones below), please share them in the comments. We don’t have established communication channels with theme and plugin authors.”
Josepha Hayden
Can We Make WordPress Releases Easier?
In her article, on Make WordPress Core, Josepha Hayden explores options on how to make the best use of volunteer contributors. Managing a volunteer team is quite a lot of moving parts, without factoring in burnout, attrition, and the pace of the release schedule. Those are real issues. Maintaining volunteerism in the Open Source Movement is hard; it’s hard in church. Volunteers are unsung heroes.
Can We Make WordPress Releases Easier for Whom?
So the question I immediately thought of when I saw the title was, “for whom?”
For the volunteers? I don’t worry about that too much. Josepha is amazing at working with people and creating an environment for collaborators.
For the users? She makes a good point in her article.
“In my observation, our users see no difference between our nuanced guidelines around minors vs majors, and currently experience each type of release (~9ish on average) as “yet another thing I have to update.”
For Plugin Developers? Hmm. I’m not certain this has been considered to scale that the plugin ecosystem has become. (Not to mention themes.)
Now, I know from leading the Make WordPress Marketing Team for two and some odd years, that “users” is a persona with a complicated Venn diagram. I tend to think of users as people like me. Small businesses that have a website running on WordPress. I’m a user of WordPress. I also have plugins on my website. Additionally, I am now a plugin developer thanks to Media Ron, LLC. See where the waters of “who is a user” is easily muddied?
As a marketer who has been working with plugin shops since 2015, I can’t help but bring up the very small window of 14 calendar days between Release Candidate and launch of the major update. With four updates planned for 2021, that felt burdensome for plugin developers — regardless of how large their shops are.
What is the WordPress Core Roadmap?
At the time of this writing, and when I wrote about the 14 day period in December, there are still four major releases scheduled for 2021.
- WordPress 5.7 March 2021
- WordPress 5.8 June 2021
- WordPress 5.9 September 2021
- WordPress 6.0 December 2021
You Chose WordPress. What Do You Expect?
Yeah, in my mind I hear Dr. Laura’s pithy, “you chose him so what do you expect” response to a wife calling about her toxic, cheating, abusive husband. (That always used to bother me.) Yeah, she chose him as the person she was twelve years ago. Now, that she’s evolved and the problem is scaled, what are her options?
Let me be clear: I’m not comparing WordPress Core to domestic violence. With that said, there is a power imbalance. That’s expected. Yes, plugin developers chose to become technically dependent upon WordPress. That’s true. So, should developers follow best practices and revolve their entire product development around WordPress’ schedule? Um. Yes and no.
What people should do and what they actually do is the middle ground that should be solved. WordPress should have a smaller schedule. Developers should subscribe to the core updates.
“Shoulds” — implied or otherwise — are the blameshifting language that divorcing couples use. It is a warning sign of an unhealthy relationship. So, I figured I would do my part and do a bit of outreach.
When Do Plugin Developers Test?
So the question is when do plugin developers test. Do they start testing at alpha? Beta 1? Beta 2? Or wait for the Release Candidate. Like most things in tech, the annoying “it depends” response is the answer.
The best case is nightly builds. But what if you have dozens and dozens of extensions that integrate with say, other dependencies a lot bigger than WordPress like PayPal and HubSpot?
“We test with the RC. And yes, 14 days isn’t very much time. We have some devs working with the nightly, but officially we test at RC.” Kevin Stover of Ninja Forms
“We run a full suite of automated tests against trunk and Gutenberg trunk every night and ramp up manual testing as soon as beta starts. We also run the Gutenberg plugin on our sites to test and work with it.” Joost de Valk of Yoast
“We have integrated automated unit testing with bleeding-edge WP for the most critical functionality.” Adrian Tobey of Groundhogg
“The beta periods last fairly long and ideally plugin devs should be testing against the betas. But there are so many “passion” projects on .org, so it’s a bit of a chore to test your free plugins.” Ronald Huereca of Media Ron LLC
“14 days feels reasonable? Can’t say I really test my free plugins and my premium ones depend more on Woo vs integrating directly with WP.” Kathy Darling
“We keep the bleeding edge versions on our dev environments and try to test related upcoming changes before the RC. Then when the RC comes out, that kind of marks the end of testing for us since things won’t change much.” Jason Coleman of Paid Memberships Pro
Plugin Developers v WordPress Core
Here’s my analysis. In the case of Plugin Developers (“devs) v WordPress Core (“Core), devs feel they have no voice on the schedule. This essentially goes against the philosophy of the Open Source Movement in their minds. Regardless of the dependencies that we choose while building the web, a healthy working relationship is important.
Core is dependent upon PHP, mySQL, Apache, jQuery, and a lot more I’m not even mentioning I’m sure. My knowledge of code only goes so deep; my specialty is strategic awareness and how that affects our ecosystem.
So, in this case of devs v core, who takes custody of the children (“users)? How do web hosts factor in? When a website is broken, the user doesn’t know what broke. Case in point, when 5.6 dropped, my Caldera Forms didn’t work. I went to my web host first (Pressable at the time), who installed the jQuery manager plugin. Support for WordPress websites will increase after a major release regardless of whose product broke or why.
Back in the days of the Growth Council, there were quite a few people chiming in on the project itself from a long-term strategic view. I think that was an important discussion to have.
Yes, WordPress Core writes about all that they do and they take feedback quite well, I’d like to add.
Here’s where I see the problem.
Even medium-to-large plugin shops don’t have a full-time developer who monitors, runs, and tests the nightly build. As far as I understand, the nightly build is the time when all of the code is done for the day and is tested against the source. This is like reconciling a cash register after someone’s shift. What broke? Where did it break? Etc.
“For Wordfence, we do some testing with alpha and beta versions, to try to catch any compatibility issues as soon as we can. I generally keep at least one of my test sites running the nightly builds, to watch for any new issues. This does get a bit more cumbersome when there are both a minor release and a major release in active development. Once the release candidates are available, we do more rigorous testing since they can contain significant changes or additional trac tickets that were not included in the earlier betas. A 14-day window does feel a bit short, especially if one or more team members is working on another project or has some time off during that period. Other factors like the PHP 8.0 release that was so close to a major WordPress release can add to the time crunch as well.” – Matt R
Notifying Plugin Developers of Changes
For my devs who are my clients, I highly recommend that they themselves get involved and subscribe to the Core Blog. This is why I’m always tweeting out when software changes. It may seem odd when a marketer is tweeting these things out except, breakage affects us all.
Ronald Huereca of Media Ron, LLC, for example, appreciates the emails that come out. They’re well thought out and helpful. He forwarded me the email he got for 5.6 and it explained all of the issues with jQuery, what plugins he has listed on the repo, etc.
For WordPress 5.6 the email was sent 23 November and 5.6 dropped 8 Dec. This is the 14 calendar day period of testing. Also, this happened during the holiday season in the States.
“IF we keep this short RC length, then we MUST be able to contact developers sooner with the Field Notes and details of changes. Anything less means plugins (and themes) absolutely will not be updated in time and we’ll have conflicts, which will lead to larger support queues for the volunteers here, as well as any webhost who automates updates. It also suggests maybe we need something better than the emails from the plugins team and instead have something automated when a Beta drops, which contains an overview of the changes, that goes to everyone with a commit bit to anything (plugin, theme, core). “ Mika Epstein
So, How About Shortening the Release Candidate (RC) Window?
The problem I see with shortening the RC window is that the window is already too short. There is also the presumption that plugin developers have fully vetted their products by the time the RC is out. Meaning, plugin developers are closely mirroring their own plugin development schedule around Core.
In an ideal world, sure. That sounds awesome.
Does it actually happen? Not really.
Many developers I reached out to don’t bother testing until the RC is out because they don’t want to duplicate work. Larger companies test against nightly builds but, as Matt from WordFence pointed out, that comes at awkward times when point releases are also being tested.
This is my comment on Make WordPress:
I love that you’re opening up this conversation, Josepha.
I’ve always believed it is burdensome on plugin shops to release Core Versions after 15 October. Most of the world celebrates holidays at the end of the year.
For example, PHP 8 dropped on American Thanksgiving and 5.6 dropped 8 Dec.
I’m also wondering if there could be more than 14 calendar days between the release candidate and launch.
Could this be changed to business days and/or extended by 5 days?
I’ve pinged some of my peers who develop plugins and I’m sure theme authors may have excellent feedback as well.
You rock!
“I think with Francesca’s suggested realignment of the phases in each release cycle, the idea is that by the time we get to RC there are essentially no new changes left to manage. The experiment to shorten the RC window is pretty new and I’m committing to it all the way, but it’ll be interesting for us to look back on it at the end of the year!”
How Long Should the RC Window Be?
I would like to see Core do a better job reaching out to plugin companies to get a feel for how testing against Core is done in practice, rather than in a perfect testing scenario. Will this be realistic on every release? No, but from a social science and research standpoint, it is important. What are the trends? What actually happens? Outreach as research is important to get the data that matters.
To study the mountain gorillas, Diann Fossey didn’t watch them on Slack or expect them to come to her. She went to where they are. She observed them. Listened to them. Drew their faces. Now, that may be super odd for the Core team to start sketching a plugin developer in the wild, but you get my point.
- How long should the release candidate window be?
- What is too short?
- What is too long?
- What is the labor burden for these releases?
- At what point will it adversely affect development shops and their users?
Who Loses When Windows Are Too Short?
My suspicion of how core releases affect dev shops is this. Keeping up with Core, especially if there really are four updates in 2021, comes at a cost to their own product development and updates. If their products aren’t at the cutting edge, then how does that ripple resonate in the WordPress ecosystem?
So, who really loses?
Without a healthy working relationship, like most dysfunctional parents, it’s the kids that suffer. The users lose. Something breaks. They don’t care what it was or whose fault it is. It comes down to a retention and branding issue. If their site is WordPress, then WordPress broke. It wasn’t Ninja Forms or Yoast. It’s not the slider plugin they insisted on installing. It’s not advanced custom fields. It’s WordPress. Regardless of the pieces of software that are assembled, it’s “WordPress.”
“WordPress breaks. We’re moving to Squarespace.” This is a direct quote from one of my large-business, non-WordPress clients. Even running their company’s website, which only changes as we publish content, has become expensive. WordPress isn’t expensive. The time managing an outside vendor is expensive. The invoices for management is expensive.
With our goal for WordPress to be the dominant CMS, we have to look at how we can set realistic goals that move Core forward at a reasonable pace that allows growth while also factoring in real-world scenarios from plugin shops.
If we don’t, at 40% of the market share, we will have a hard time getting to 51% of the market. As an ecosystem scales, its faults scale.
If we don’t achieve our 51% market share, who loses, then?
It will be plugin shops first, because they’ll lose end-users to Squarespace, Webflow, and Wix. (This is the time to think about a SaaS move.) Without users, there is no revenue. Without revenue, marketing folks and developers will lose employment. I personally know WordPress developers working for Shopify.
WordPress the Project will lose because plugin developers won’t have the time or money to sponsor full-time volunteers to work on the project. The web hosts will have to continue to do the heavy lifting as far as that goes, much as they are doing now. Last I heard, Bluehost has 8 full-time employees who work on Core. I imagine that number is larger in the 16 months since I’ve talked to them at a WordCamp. That doesn’t account for the employees that are full-time sponsors from Yoast and anyone else I can’t think off.
WordPress.com will lose, not to the same degree, but Automattic will have to pick up the slack from the attrition of companies who sponsor full-time employees to work on the project. Sure, dot com and Automattic, in general, have what seems like a bigger part of the pie, but they also have a bigger part of the overhead. Automattic is not only accountable to their product teams and employees, but their vendors and clients. Let’s not forget their fiduciary duty to their investors as well.
When “WordPress” the brand doesn’t work, it affects us all. Maybe not to the same degree, but it will affect our reputation.
“Oh you’re going to use WordPress? Doesn’t that break?”
We have to do better.
Shortening the Release Candidate window is not a good move for Core. The domino effect is too grave.