[wp-meta] [Making WordPress.org] #484: WordPress version should come from parsed wp-includes/version.php version

[Making WordPress.org]

#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