Categories
Developer Advisory

Announcing a change to the WooCommerce Blocks Version Support Policy

To enable more efficient and effective development of experimental features powered by the WordPress Gutenberg project, the support policy for WooCommerce Blocks is switching from L2 to L0. This effectively means that beginning with WooCommerce Blocks 5.6.0, the feature plugin will require the latest versions of WordPress and WooCommerce.

Background

For the past two years, the WooCommerce Blocks project has followed a policy where the feature plugin always supports the last two releases of WordPress and WooCommerce (excluding fix releases). For example, a release of WooCommerce Blocks today would require:

  • WordPress 5.6.x (latest version branch of WordPress at time of this post being published is 5.8)
  • WooCommerce 5.3.x (latest version branch of WooCommerce at time of this post being published is 5.5)

This policy aligns with what WooCommerce core follows for WordPress version support and was, in part, to help manage the increased complexity in the codebase that results from ensuring compatibility with WordPress and WooCommerce core. In the case of WordPress, this is especially important because each WordPress release effectively represents several releases of Gutenberg.

WooCommerce Blocks depends on Gutenberg, so the complexity required for WooCommerce Blocks hinges on the number of Gutenberg releases in each release of WordPress and the amount of change each of those releases represents.

Keeping in mind that WooCommerce Blocks operates with a similar paradigm to other feature plugins in the WordPress ecosystem (such as the Gutenberg plugin), this does not mean we are lax with testing or okay with breaking things, but it does mean that we set the expectation that this is a plugin for previewing the latest experiments we are working on for potential general release in WooCommerce core. From the description on WordPress.org:

Note: Feature plugin for WooCommerce + Gutenberg. This plugin serves as a space to iterate and explore new Blocks and updates to existing blocks for WooCommerce, and how WooCommerce might work with the block editor.

Use this plugin if you want access to the bleeding edge of available blocks for WooCommerce. However, stable blocks are bundled into WooCommerce, and can be added from the “WooCommerce” section in the block inserter.

Feature plugins provide a way for us to get early testing and feedback on things we build that use newer APIs and interfaces available in WordPress and WooCommerce. However, even with using the latest API’s and interfaces available to match the policy, we are still effectively testing against features and interfaces that are at least ~2 months old in WooCommerce core and ~7-9 months old in WordPress. This means that WooCommerce Blocks will always be lagging behind on what UX/UI improvements are available for us to build with — even more so when you consider that the development and feedback phase of the releases in the feature plugin also requires additional time.

While for the most part we’ve been able to work within those constraints for some of the things we’ve been experimenting with, we have been encountering some headwinds for continuing with the L2 policy. As a result, effective with the release of WooCommerce Blocks 5.6, we will be shifting to a L0 policy. What this means is that from the release of WooCommerce Blocks 5.6 forward, the feature plugin will always require the latest version of WooCommerce Core and WordPress at the time of its release. With WooCommerce Blocks 5.6 this would mean the minimum required version of WordPress will be 5.8 and the minimum required version of WooCommerce will be 5.5.

Why?

This decision was not made lightly and one we carefully evaluated. In the end we decided to do this for the following reasons:

Pace of Gutenberg development

The pace of Gutenberg development has always been fairly fast but it has accelerated even more with the advent of full site editing and the new improvements coming with it in the form of various block APIs and interfaces. To effectively prepare WooCommerce for future releases of WordPress and fully utilize the benefits these improvements bring, it’s important that we stay close to current development within the Gutenberg plugin. This has several advantages including:

  • Our team can be involved in the active development of various new Gutenberg interfaces and features.
  • We can be participating in contributing and testing these things against the needs of the WooCommerce ecosystem and help influence the outcome for not only WooCommerce but also other plugins in the ecosystem.
  • We are able to surface these new interfaces quicker to merchants and shoppers via the feature plugin with the certainty that we’re evaluating against the most up to date changes in the stable release WordPress.

Less complexity in the codebase.

When developing new features, there is less need for us to account for the added time, development, and technical debt incurred with devising shims or workarounds for things we need from various WordPress packages that are not available in the older versions of WordPress we support. This also brings potential performance improvements.

Encourages keeping up to date.

Every WooCommerce store has a variety of needs met by extensions, themes, and potentially, custom development. For some, this can impact the time involvement for keeping all the software up to date with their latest versions. While we recognize this, we do feel it’s in the best interest of stores from a business perspective to build into their business plans the cost of keeping their online presence up to date. In the online world this is especially important given the evolving improvements to security, user experience, and performance as WordPress and WooCommerce (and its ecosystem of plugins and extensions) are iterated on – all things that in turn have a positive impact on the success of merchant’s online presence.

With that in mind, given the purpose of the WooCommerce Blocks feature plugin in giving previews into what is potentially coming to the WooCommerce core experience and providing an opportunity for those using this to provide feedback to help shape that, we want to make sure folks using this plugin are testing against the latest feature set available from WordPress instead of something that is already 7-12 months behind.

What about requiring the latest version of WooCommerce?

You may have noticed I’ve been mostly focusing on the benefits of supporting the latest version of WordPress, but haven’t really touched on WooCommerce yet. In this case, the rationale is simple. Any new features or blocks we develop will only surface in the most recent WooCommerce version. So from the perspective of new development or updates to existing functionality, all the things within the WooCommerce blocks plugin will require the latest version of WooCommerce.

What kind of impact will this have for existing stores using WooCommerce Blocks?

If you are already keeping your store up to date with the latest WordPress and WooCommerce versions, you can skip this section! Otherwise, read on.

Thanks to existing functionality in WordPress and WooCommerce that prevents updating or activating a plugin that requires versions not available in the environment, beginning with WooCommerce Blocks 5.6:

  • If you are using any WordPress version less than WordPress 5.8, you will not be able to update (from the WordPress plugin interface) to the latest version of WooCommerce Blocks.
  • If you are using any WooCommerce version less than WooCommerce 5.5, you will be able to update and WooCommerce Blocks will activate, but it will not fully load (and will show an admin notice).
  • If you update via FTP or some other direct method, and your environment contains an unsupported WordPress or WooCommerce version, you will be unable to activate the WooCommerce Blocks feature plugin in the case of missing WordPress version requirement. You will be able to activate WooCommerce Blocks if you’re missing the WooCommerce version requirement, however, the feature plugin will not completely load and there will be an admin notice about the incompatibility.
  • Any blocks in the WooCommerce feature plugin that are also bundled similarly in WooCommerce core will still function if the plugin doesn’t activate (or load completely). However, if you have blocks active that are either not available in WooCommerce core yet, or are changed in the feature plugin, these will likely break with the feature plugin inactive. So you are advised to not update via any of the above methods unless you have verified your Store meets the minimum requirements.
  • Those unable to update will still be able to use the prior release of WooCommerce Blocks.

In Closing

In making this decision, we also took a look at what versions of WordPress and WooCommerce were in use among users of the WooCommerce plugin and discovered the majority of feature plugin users are on the latest versions. If you are one of the few that isn’t, I’ll reiterate this decision wasn’t made lightly and I hope this post helps highlight for you the rationale behind making it.

We’ll definitely be watching the comments here in case any of you have additional questions or need clarification.

By Darren Ethier

I’m the father of four children and husband of the most beautiful woman in the world. My passion is developing useful and pretty code. I also love anything to do with leadership and the wise use of words.  Currently I'm employed as a Code Wrangler with Automattic and an engineering team lead for a team working on WooCommerce.

5 replies on “Announcing a change to the WooCommerce Blocks Version Support Policy”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.