Making WordPress.org

Opened 9 years ago

Closed 9 years ago

#1034 closed enhancement (wontfix)

api.wordpress.org/plugins/update-check/1.1/ enhancement

Reported by: brettshumaker's profile brettshumaker Owned by:
Milestone: Priority: normal
Component: API Keywords: close
Cc:

Description

Just want to open a discussion about the way we're checking for plugin/theme updates. Consider the situation where a user has a plugin with a version of 1.02 and the developer building the plugin realizes that s/he should be using semantic versioning so they release an update with a version of 1.1.0. Makes sense, right? A young developer is trying to correct a mistake they did, but WordPress doesn't behave "logically" and does not trigger an update for users of the plugin. The only course of action the developer has in this instance is to issue another update to their plugin with a version of at least 1.2.0, which could be confusing for the end user.

Currently the API uses version_compare() and I feel like the issue could be solved by instead using strnatcmp(). I'm sure it's been done this way for a long time and I was not involved with WordPress when the initial decision was made to use version_compare() but can anyone think of any instances where strnatcmp() would fail at recognizing a newer version of a plugin/theme in the repository?

Thanks!

Change History (6)

#1 @Otto42
9 years ago

Versions aren't decimal numbers. It seems like a long way to go to change away from semantic versioning, a tried and tested technique which is even built into PHP, to allow for non-semantic versioning.

1.02 > 1.1.0, and that's the way it very much should be. I think it's a bad idea to support non-standard versioning methods for an extremely rare case.

#2 @dd32
9 years ago

I don't think we should change anything here myself. Versions numbers are not supposed to follow human decimal rules, so 1.04 should be read as 1.4.
The best way to think about it, is to drop the decimal notation you're accustomed to and read it as major: 1, minor: 04, major: 1, minor: 1 - so in that case 04 > 1.

version_compare() is designed to handle PHP-formatted version strings, which are the same strings WordPress is built to expect. There's a bit of a blurb on http://php.net/version_compare on how it works.

#3 @dd32
9 years ago

  • Keywords close added

#4 @brettshumaker
9 years ago

Good points. Just thinking about those just getting into developing plugins/themes. If WordPress expects PHP-formatted version strings, I think there should be a mention of semantic versioning as being the preferred method on https://codex.wordpress.org/Writing_a_Plugin#Standard_Plugin_Information with links to learn more information about it. That way we can encourage good versioning habits from the beginning?

#5 @dd32
9 years ago

WordPress itself doesn't use semantic versioning, and I don't think we should recommend it either.

The versioning system which WordPress, and the majority of plugins follow, is mostly decimal (I know, I just pointed out above that we don't use decimal) in that 2.0 & 1.9 are both major releases, we tend to follow the major.major.minor versioning system - for example, WordPress 4.2.2 is really 42.2 in semantic versioning (We just don't use the patch level).

https://make.wordpress.org/core/handbook/how-the-release-cycle-works/version-numbering/ describes it as well.

Likewise, we would highly recommend against using major.minor.micro.patch format that some plugin have used in the past (and subsequently seen the error in their ways, and changed).

#6 @Otto42
9 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

While WordPress doesn't exactly use semantic versioning, it is close enough for version_compare to work properly for it.

So, whether we actually recommend semantic versioning or not, we do support it and it works for plugins and themes. People can use it, or copy WordPress's versioning style, or do whatever they like that works with version_compare.

I don't mind major.minor.patch styling. It works fine and we do support this style in the theme and plugin directories.

Note: See TracTickets for help on using tickets.