Changelog

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!

(more…)

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.