Categories
Core

Important update regarding the upcoming WooCommerce release; 2.7 will be 3.0.0

tl;dr: We’re re-versioning WooCommerce 2.7 as WooCommerce 3.0.0, and releasing this on 4th April 2017. We found a critical bug in the way the system handles timestamps, which wasn’t caught sooner, and have had numerous requests from third-party extension developers for more testing time, due to the scale of changes in this release.

This past week we’ve been having several conversions about 2.7 both internally and with some 3rd party developers to get feedback about the new release, and to discuss the new CRUD system.

From those discussions and from feedback in our RC/beta posts it was clear developers would like a little more time to test and would appreciate longer RC periods in the future. It was also requested that versions were more descriptive of what was actually inside the release.

We also found a few issues specific to timezone handling and timestamps, which we felt would be better handled before release, simply because if we don’t do it now this could cause issues with method naming in future releases. Essentially, some developers need a way to reliable get UTC timestamps as well as dates according to the site’s timezone.

To resolve this we’re working on a solution which accepts either a UTC timestamp, or an ISO8601 datetime string, and returns a DateTime object so timezone information can be retrieved if needed. This approach is not compatible with the get_date_x getters found in 2.7 beta.

Given that the timestamp changes would prolong the release candidate anyway, we decided it was not too late to consider semantic version numbers. With that, the idea of 3.0.0 was born.

Semantic Versioning (SemVer) going forward

WooCommerce has, up to now, numbered it’s versions incrementally (2.0, 2.1, 2.2, 2.3 and so on) with those increments containing a mix of fixes, refactors, new features, and “breaking” changes. The actual numbering has no indication to what is actually going into a release, and like WordPress, those increments are treated equally.

For example, the update from WordPress 3.9 to 4.0 was no more significant that the upgrade between 4.1 to 4.2. It’s just a number.

We’ve had concerns from some developers that our versioning could be misinterpreted and, like WordPress, lacked real meaning.

It’s a major release hiding under an inappropriate version number.

This lead to an internal discussion about why we version how we do now (just to mimic WP), and what we could do instead. We decided to adopt SemVer.

SemVer dictates that:

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards-compatible manner, and
  • PATCH version when you make backwards-compatible bug fixes.

Using this we hope that are version numbers better reflect the types of changes we’re making, and that there is increased confidence over patch and minor releases where we’re introducing changes but not affecting extensions in a negative way.

3.0.0 will be a major update. Whilst we’ve taken every opportunity to make things backwards compatible (with deprecation notices), there are some known documented gotchas, and we have changed the fundamental way in which WooCommerce data should be accessed.

3.1.0 will be a minor update in which one of the things we want to introduce is a new product importer. This is roadmapped on Github if you’d like to learn more.

With Semver, if we did need to make a major change after 3.0.0, we’d put that change on hold until the next major (4.0.0) update.

What will the 3.0.0 RC1 look like?

3.0.0 RC, which should be tagged later in the week, will be very similar to 2.7 RC 1 with the addition of several fixes and these important changes;

  1. The versioning and @since properties will be relabeled to 3.0.0. If you have used version_compare statements in your code, they will still work since 3.0.0 is greater than 2.7.0 🙂 You can change these for clarity however.
  2. There will be a resolution to this critical timezone/timestamp issue which we want to resolve before release.  This changes the return type of get_date_x type methods from integer to DateTime and so will need to be handled in extensions if those getters have been implemented already from the 2.7 RC.
  3. Themes with 2.7.0 versioned template files may need to update those to 3.0.0 versions to prevent reports of outdated template files.

When will 3.0.0 launch?

We’re aiming to have the RC tagged in a few days allowing for ~3 weeks testing prior to final launch.

The final launch date, if things go as planned, will be April 4th 2017. 

This should be enough notice to do a final round of testing and to account for the changes highlighted further up in this post.

By Mike Jolley

I help build things at Automattic.

40 replies on “Important update regarding the upcoming WooCommerce release; 2.7 will be 3.0.0”

Ok Google: Insert jaw drops open emoticon, then the head scratching emoticon, then the jaw dropped open again, then a sigh of relief thingy, followed by a thumbs up emoticon.

Liked by 5 people

I’m very happy to see these changes. Big props for making the tough call late in the release cycle. Hopefully it will help ensure a smoother release for all WC users of this version. 🙂

Liked by 4 people

I welcome the new semantic versioning. I was amongst the developers who requested it, quite a while ago, and it’s great to see it. 🙂

Regarding 3.0.0, key question: are there going to be any significant changes from the existing 2.7 RC1? In other words, assuming that a software X has been tested and is compatible with 2.7 RC1, can we assume that it will work with 3.0.0 as well? Of course, re-testing will be done as a precaution, but it would be good to know if there are clear pitfalls to look for. Thanks.

Liked by 1 person

I checked the three points already, they don’t affect anything I do. I was more concerned about any other changes introduced as in “while we were at it, we also did X”, but I seem to understand that there aren’t any.

Like

Thanks Mike, I think this is a really positive move forward for WooCommerce. I for one want to thank you on behalf of all the third party devs for being so open and taking on board all of our various points, really make us happy to be part of the community!

Liked by 6 people

I wonder how many themes this is going to break. I have already seen warnings about Avada (you MUST update to the new version of Avada otherwise it will break all previous versions) and I have been told by a colleague he received a similar warning about Enfold, both very popular themes. People who don’t see or get warning emails from theme authors (I only found out from a Facebook group) and have auto-update set up are likely to get a very nasty surprise any time soon…

Like

Important note; only template files which we modify in core get a version bump.

It’s better to show a warning about an outdated template than “break” without any obvious reason; thats why template files are versioned. An outdated template file doesn’t guarantee you’ll actually have any problems on the frontend, but it needs to be reviewed.

You can actually theme without overriding templates like Storefront does, so there are other options for theme devs if problematic.

Liked by 2 people

I think the biggest and most useful change for many in the community would be to create a LTS (long term support) version that is maintained with security only updates.

Having made numerous custom changes for my client, I cringe every time a new version of WooCommerce and WooCommerce Subscriptions is released, so I end up not updating the site for quite a while. I don’t need any new features on a stable/working site and just want to be up to date with security updates.

Liked by 3 people

I tend to disable auto updates since it breaks things and I try to minimize the number of extra extensions used. I do those manually after first testing on a dev server. Most extensions/plugins/widgets are fairly simple and can be easily tested. WC and WCS are much more sophisticated and testing is much more cumbersome.

Also, in the past WC tended to be aggressive with bumping the minimum required version of WP. In many cases I am forced to upgrade or backport a security fix. That becomes an expensive proposition for the client who doesn’t understand why several hours of testing is needed for no new capability.

I do think it is a problem that needs addressing especially since the eco system of WP/WC caters to a substantial e-commerce audience. It is one thing if your hobby blog auto-updates and has some downtime, but another if your credit card transactions are not working.

Liked by 2 people

Just take an afternoon on o cloned staging server and test everything thoroughly. Report any bugs you find to respective developers, then wait until all bugs have been solved, then update. It is a lot of work, but you only need to do it rarely since I bet 4.0 is quite a while away after this one.

Like

I am happy you decided to go this way with versioning! It makes much more sense.
Keep up the good work legends.

Like

In WooCommerce > Settings > Tax > Standard Rates, can you please make the Import CSV function capable of recognizing and re-formatting the data within columns more broadly? For example, the city tax rates consistently shown in the “Rate” column of California’s Board of Equalization “City_Rates.csv” uses this format: 7.25%. If WooCommerce could simply recognize the percent symbol and automatically delete it upon import, this would be a huge factor. (This is just one of several import improvements needed though.) This issues may not sound like a big deal, but in California the sales tax rates change frequently, affecting many of its 1,785 cities – sometimes statewide, affecting ALL 1,785 cities. When broader tax rates change, the step-by-step process I have to go through to get the state’s .csv file to successfully import into the “Standard” Tax Rates table is like a freakin’ NASA mission. It’s a pretty serious weakness in WC which consumes a great deal of my time in getting the tax tables updated successfully. Mike Jolly, or anyone at WC,may contact me if more info is needed. Please address this, thanks.

Like

Hi Mike and everyone, I have done the update for the woo commerce 3.0 and the webshop is no longer showing the products. What files changed during the update to woocommerce 3 from 2.6.14? We use the thema savoy. We tried to reverse the update and go back to the old version to see if it would come back but it did not work anyway…
Could someone help me???
Thanks!!!
Rui Vieira

Like

To anyone planning to update and who is running a store, ALWAYS use a staging server where you test updates before updating your live site. Also ALWAYS take a backup of your live site before deploying major updates so you can restore to a functioning state if you run into problems.

Just some friendly advice so you don’t have to be that store owner with a broken website and no way out of your situation.

Like

Hi everyone,
Just updated woocommerce on the 3.0 version, and now can not edit or modify anymore informations related to a single product.
Any suggestions ?
Thxs

Like

I’m trying to understand for how long you can stay with WooCommerce 2.6.x?
I have tried WC 3 and my site fell over and I cannot find a quick fix so am about to restore a site backup when I was on 2.6.x

Anyone know how long I could stay on 2.6.x?

I know that perhaps some plugins may update for version 3 and lose vers 2.6 compatibility in time but, right now, how long do I have?

Thanks.

Like

How can fix this
“Notice: is_in_stock se llamó incorrectamente. No se debería acceder a las propiedades del producto directamente. Backtrace: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/plugins/woocommerce/templates/taxonomy-product_cat.php’), wc_get_template, include(‘/plugins/woocommerce/templates/archive-product.php’), wc_get_template_part, load_template, require(‘/plugins/woocommerce/templates/content-product.php’), do_action(‘woocommerce_before_shop_loop_item’), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, storefront_woocommerce_init_structured_data, WC_Abstract_Legacy_Product->__get, wc_doing_it_wrong Por favor, visita
Depuración en WordPress para más información. (Este mensaje se añadió en la versión 3.0.) in /home/frame/public_html/wp-includes/functions.php on line 4138”

Like

I tried the update and everything broke. I had to restore an older version. This clearly was not tested or given other plugins an opportunity to test against it prior to release. Bad form!

Like

Comments are closed.