Version numbering proposal

[DJPaul]

Any interest in adopting a new version numbering system for our 3.0?

Such as ​https://jwong.co.uk/blog/2018/02/23/a-proposal-for-changing-the-wordpress-versioning-scheme/

?

[boonebgorges]

What would be the goal? To make backward compatibility changes clearer? Are you proposing we use actual SemVer, or something like Jenny's modified proposal?

[netweb]

Do it I say, switch to 100% semantic versioning, technically though without WordPress Core adhering to it also there's a chance strictly speaking that a WordPress update could break BuddyPress'

Personally, I'm not a fan of any "semantic-like versioning" proposal as I believe they introduce more confusion

There's a comment on Jenny's post linking to the commenters blog ​https://alexandergoller.com/semantic-versioning-wordpress-userland/ that includes a few links to other plugins journey into semver:

• ​https://kb.yoast.com/kb/plugin-version-numbers-and-frequent-updates/
• ​https://woocommerce.wordpress.com/2017/03/13/important-update-regarding-the-upcoming-woocommerce-release-2-7-will-be-3-0-0/

The WooCommerce post was what convinced me SemVer can work:

• I don't see any issues that would require changes to plugins such as ​automatic updater and they would continue to work as-is.

• The next release of BuddyPress would be 3.0.0 instead of 3.0

• I was thinking that not often a major version bump would be required and BP would remain on the 3.x branch for eternity, but further thinking when BP drops WP 4.6 a major version bump would be required, BPs REST API, BPs WP-CLI implementations will also offer opportunities to iterate and produce v2's of these APIs and major version bumps.

p.s FYI: For reference though I couldn't find said reference to the original discussion, a few years ago an informal discussion took place in regard to WordPress version numbers, at the time the suggestion was to use something like Google Chromes versioning e.g. 66.0.3355.0, and this was thought of the best way forward to Core further enhancing automatic updates, which includes automatic updates for major releases, an eventual goal to even update the 3.7.x branches to the latest 4.9.x is still thought of as a possible goal.

[netweb]

Related: ​#WP43495 Use Semantic Versioning for releases

[DJPaul]

This is going to be potentially confusing, so bring your peril-sensitive sunglasses:

The JWO idea is missing an identification for minor feature changes. So, if I can amend that for that, it ends up like:

MAJOR – New Feature: when there is a major feature or incompatible API change,
MINOR – Bug Fixes: when you add scheduled bug fix or enhancement in a backwards-compatible manner, and
PATCH – Security: when you make security fixes in a backwards-compatible manner.

Now, if I take SemVer 2, and tweak the wording to represent the reality that a incompatible major breaking change in BuddyPress is fairly rare, it ends up like:

MAJOR version when you make incompatible API changes or major feature,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes. (security fixes are backwards-compatible bug fixes)

At which point these are basically the same. It's just semantics. I think people who parse SemVer numbers won't be put-off or confused by the change the MAJOR Version meaning, and ditto for the folk used to something like WordPress' versioning numbering for the MINOR part.

For the people who don't parse version numbers and just read them as a string of numbers (all non-tech people?), these sorts of change won't have any impact on them.

[DJPaul]

I remain keen on adopting this for the release after 3.0.

X.y.z
X = major feature
Y = minor bug fix
Z = security

[DJPaul]

We did this.