[wp-trac] [WordPress Trac] #43495: Use Semantic Versioning for releases
WordPress Trac
noreply at wordpress.org
Thu Feb 11 22:30:26 UTC 2021
#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
More information about the wp-trac
mailing list