[wp-meta] [Making WordPress.org] #484: WordPress version should come from parsed wp-includes/version.php version
Making WordPress.org
noreply at wordpress.org
Thu May 22 17:23:44 UTC 2014
#484: WordPress version should come from parsed wp-includes/version.php version
---------------------------+-------------------------------------
Reporter: keesiemeijer | Owner: coffee2code
Type: enhancement | Status: accepted
Priority: normal | Component: developer.wordpress.org
Resolution: | Keywords: has-patch needs-testing
---------------------------+-------------------------------------
Comment (by coffee2code):
True, but at that point it's a bit of an edge case (or will be). This
concern only affects non-developer.wordpress.org installs, which would
generally be local devs.
For the approach that also uses $wp_version to fail, the site would have
to be non-dotorg (''thus no constant''), running an older version of the
parser or still using older parsed data (''thus no option defined''), and
probably using trunk for their local devhub site (''leading to an invalid
version''). All are possible for the handful of devs currently involved.
However, returning an empty string won't make things much better. Not
unless we account for that whenever `get_current_version()` is called.
I would rather return a hardcoded value that is known to be valid (e.g.
"3.9.1") rather than an empty string. Everything would thus still work,
even if the version number doesn't correspond to what was actually parsed.
We could check to see if $wp_version has a dash, which would indicate a
non-release version. In which case we'd fall back to a hardcoded value.
--
Ticket URL: <https://meta.trac.wordpress.org/ticket/484#comment:5>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org
More information about the wp-meta
mailing list