WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 19 months ago

#43495 closed enhancement (wontfix)

Use Semantic Versioning for releases

Reported by: netweb Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

Via todays #core dev-chat: https://wordpress.slack.com/archives/C02RQBWTW/p1520470243000286

Dion wrote:

4.10 instead of a 5.0 isn’t likely to work very well, other than the fact that it moves us from using decimal versioning to semantic versioning, I feel we might have some locations where we expect a branch is 3 digits, but that might not be the case. If it’s simply to avoid the 5 number because we’ve suddenly decided the first digit is actually special, then maybe it’s time to set a plan in place to adopt semantic versioning over the next few releases.

Background context: The question was posed, can a release numbered 4.10.0 be released as a major version instead of a minor version

What is Semantic Versioning?: Semantic Versioning is a formal convention for specifying compatibility using a three-part version number: major version; minor version; and patch. https://semver.org/

Change History (6)

This ticket was mentioned in Slack in #buddypress by netweb. View the logs.


3 years ago

#2 @Luciano Croce
3 years ago

I consider this proposal very interesting'''

I am in favor of this introduction, but perhaps we should start from 5.0.0 in order to maintain the backward compatibility with the system adopting up to now with version 4.9+ and earlier.

#3 @jdgrimes
3 years ago

I am definitely a fan of semantic versioning, but I think it is important to realize that we can't just decide to change how we version core without some major implications. The update code currently treats 4.5.0 as a "major" release, and 4.5.1 as a "minor" release (core's terminology). Both of these effectively map to semver's "minor" release. There is no concept of a "breaking" release or a "patch" release, as semver defines them. The code in core (and probably any plugins/themes/etc.) that relates to core updates will have to be changed. But so will users' perception of what to expect from updates. In short, this would be a breaking change, as @Luciano Croce pointed out, so there is no way that there could be a 4.10.0 following semver. It would have to be a 5.0.0 that made the switch.

In addition, because core attempts to maintain almost-infinite backward compatibility, if we switched to semver WordPress would in theory always be on 5.x, because there would never be a breaking release to usher in 6.x. Of course, the reality is that core just ends up making little breaking changes all of the time, once it is safe to do so without much chance of actually breaking any code out in the wild.

In the end, what we would really be contemplating here would be a complete change of philosophy for WP in regard to versioning, backward compatibility, patches, minor updates, etc. Although part of me would prefer that core embraced semver, core has a somewhat unique situation in regard to its technical debt, scope, and diverse versioning audience, and there is wisdom in some of the philosophies that it has embraced here, which are not really compatible with semver.

TL;DR: semver is not just a way of specifying version numbers, it implies an entire versioning philosophy, and it runs counter to the versioning philosophy embraced by WordPress core. There is a lot that would have to be considered before a change like this could be made.

This ticket was mentioned in Slack in #core by luciano. View the logs.


2 years ago

#5 @pento
2 years ago

  • Keywords 2nd-opinion dev-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Semver certainly has it's uses, and I'm absolutely in favour of it being used for new development (for example, the packages we release on NPM all use semver). It isn't a viable option for WordPress, however.

WordPress is a huge code base, with 15 years of history (and the years before that as b2!). We do occasionally make small breaking changes, but we try not to. As @jdgrimes mentioned, moving to a versioning system where we explicitly make breaking changes would be a huge philosophical change to how WordPress is built.

This is also in opposition of the ultimate goal of auto-updating all WordPress releases, not just the minor ones. Much like the version number of Chrome, or iOS, or Pokemon Go don't actually matter, neither should WordPress' version number matter: it mostly just needs to be an indicator of "this version was releases before/after that version". Trying to shoe-horn a versioning regime around that is an unnecessary restriction.

This ticket was mentioned in Slack in #cli by jpry. View the logs.


19 months ago

Note: See TracTickets for help on using tickets.