[wp-trac] [WordPress Trac] #43495: Use Semantic Versioning for releases

[WordPress Trac]

#43495: Use Semantic Versioning for releases
-----------------------------+----------------------
 Reporter:  netweb           |       Owner:  (none)
     Type:  enhancement      |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Upgrade/Install  |     Version:
 Severity:  normal           |  Resolution:  wontfix
 Keywords:                   |     Focuses:
-----------------------------+----------------------

Comment (by eclev91):

 I disagree with a couple takes here, and would like to see this ticket
 reopened.

 > a complete change of philosophy for WP in regard to versioning, backward
 compatibility, patches, minor updates, etc.

 > moving to a versioning system where we explicitly make breaking changes

 I don't think SemVer forces either of these things. A dedication to
 backwards compatibility is a philosophy, not a versioning system. A
 versioning system is simply a standardized means of communication that
 (and this is important) an automated system can understand.

 Let's assume WordPress had never broken backwards compatibility. 5.6.1
 would have, rather, been 1.39.1. And there's nothing wrong with that!
 SemVer doesn't care. With the block editor, we'd more realistically be
 looking at 2.6.1, but the point is that whatever number you arrive at,
 it's simply a result of your philosophy and practices.

 > This is also in opposition of the ultimate goal of auto-updating all
 WordPress releases, not just the minor ones.

 I think SemVer would actually be a huge benefit to this process. Both
 technical and non-technical users should feel safe enabling auto updates
 for Z updates, and likely even Y updates (given X.Y.Z). Auto-enabling Y
 and Z updates out of the box would be a pretty safe decision. I'd argue,
 in fact, that the current "update everything" default is super
 irresponsible, especially since WordPress core can't attest to the
 integrity of third-party plugins and themes. Without SemVer, there's no
 way to implement an automated system somewhere in the middle.

 I would even argue the opposite is true - not having SemVer, paired with
 the new auto-update system, forces WordPress core to never make BC-
 breaking changes (see the fallout during the WP 5.0 release - "why is my
 site broken!?"). With SemVer, avoiding BC-breaking changes is a
 (commendable) philosophy, not a requirement.

 > We do occasionally make small breaking changes, but we try not to

 This kind of sucks. SemVer, and an auto-update system that was cognizant
 of it, would encourage core to collect these changes under the banner of a
 major (as defined by SemVer) release, which communicates pretty succinctly
 to plugin authors and technical site maintainers "Hey, you should
 ''definitely'' read the developer release notes." Right now, it's easy to
 fall into a trap of mostly ignoring core releases if you don't have
 automated testing set up.

 Meanwhile, laypeople ''could'' opt-in to major release auto-updates, which
 should be few and far between anyway, because the WP release philosophy
 shouldn't change.

 > Much like the version number of Chrome, or iOS, or Pokemon Go don't
 actually matter

 I'm not an iOS or Chrome extension developer, or an workstation
 provisioning manager in IT at an enterprise company, so I don't ''know''
 this, but I assume those version numbers ''do'' matter to certain
 individuals. It's just obfuscated to everyday users. Not sure how SemVer
 precludes this from being WordPress's ultimate goal.

 And finally, WordPress is clearly setting the precedent for plugin authors
 and their versioning system (see the recent backpedaling by WooCommerce on
 SemVer), which is all the more frustrating for technical site maintainers.
 With large numbers of clients and automated systems, the more risk I can
 mitigate in a one-click update process, the better. I shouldn't have to
 read the changelog for every plugin on every client site to know when it
 is or isn't safe to update.

 Once again, for the lay-person, they can either opt into major auto-
 updates or just minor ones as a sensible default. You can even stick to
 the "Decisions, not options" mantra here. SemVer allows core to make a
 more ''responsible'' decision in defaulting to minor release auto-updates,
 and provide an advanced setting for users who want major updates as well
 (or who want to disable all auto-updates), just like today.

 What's standing in the way of adopting SemVer? Sounds like some changes to
 core update logic and a consensus? Would love to hear more input.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43495#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform