Changelog

WooCommerce 3.0.0 RC2 is available for testing. This fixes a bunch of issues from 3.0.0 RC1 which we’ve spent the last 2 weeks working on. Notable fixes include:

• Fixed some edge case gallery issues such as galleries with no images, and zoom image sizes when flexslider is not used.
• Fixed the 3.0 db updater to correctly set the outofstock term.
• Fixed double add to cart issue on cart page when querystring contains add-to-cart.
• Fix coupon removal in cart.
• Added __sleep and __wakeup methods to data stores and data objects to avoid full object serialisation. Because of this, we were able to remove the special handling in email cron (since this is better), and remove the now defunct object caching in the data stores.
• Prevent max on qty selectors being set to -1.
• Improved default column definition in admin screens.
• Fix to allow custom order item types from 2.6.
• Fixed some bugs in the legacy API (using incorrect getters).
• Various docblock/deprecation notice corrections.
• Various RTL fixes.
• Various fixes to prevent notices e.g. by casting floats when doing arithmetic.
• Fixed API to return names instead of slugs in variation API.
• Various REST API v2 schema and return type corrections (to match docs).
• Removed timezone guesswork from set_date_prop method so offsets are correctly handled when the WP timezone setting is set to a UTC offset.

The REST API v2 docs are also now live so be sure to check out what is now possible with 3.0.0 and the v2 API if you’re using it.

To test WooCommerce 3.0.0 RC2, you can use our WooCommerce Beta Tester plugin or you can download the release candidate here (zip).

Think you’ve found a bug? Please post in detail to Github.

The final version of 3.0.0 is still due for April 4th 2017. Huge props to everyone who has sent feedback about this release so far or found bugs.

This was quite the week. A few days ago we announced the decision to reversion and release 2.7 as 3.0.0. This was due to finding a critical bug in the way the system handles timestamps, which wasn’t caught sooner, and requests from third-party extension developers for more testing time. At the same time we chose to adopt semantic versioning going forward to make releases clearer.

Today, the release candidate for WooCommerce 3.0.0 “Bionic Butterfly” is available!

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.