Skip to:
Content

BuddyPress.org

Opened 3 years ago

Closed 2 years ago

#7710 closed task (fixed)

Version numbering proposal

Reported by: DJPaul Owned by:
Milestone: 4.0 Priority: normal
Severity: normal Version:
Component: Core Keywords:
Cc:

Description

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/

?

Change History (8)

#1 @boonebgorges
3 years ago

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?

#2 @netweb
3 years ago

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:

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.

#3 @netweb
3 years ago

Related: #WP43495 Use Semantic Versioning for releases

#4 @DJPaul
3 years ago

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.

#5 @DJPaul
3 years ago

  • Milestone changed from Awaiting Review to Under Consideration

#6 @DJPaul
2 years ago

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

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

This ticket was mentioned in Slack in #buddypress by r-a-y. View the logs.


2 years ago

#8 @DJPaul
2 years ago

  • Milestone changed from Under Consideration to 4.0
  • Resolution set to fixed
  • Status changed from new to closed

We did this.

Note: See TracTickets for help on using tickets.