Versioning structure

[joyously]

I might have missed where this was discussed, but I don’t quite see how the CP directory solves the problem the WP repo has with versioning.

As far as I can tell, the only version the WP API will serve is the one marked as Stable Tag, although the previous versions are available for manual download. What this does is give the users a false sense of being up to date. For WP releases, the update nag is there, but it can be ignored for years. When it is, all the plugin updates are also ignored because the version numbers don’t match.

I’ve heard that CP will keep 1.x working “forever”, so when 2.x and 3.x are out, wouldn’t they need a different set of plugins? And are they all in one directory? Is the latest version of the plugin the only one that is available?

Take a look at Statistics | WordPress.org to see that there are so many versions being run that the repo doesn’t help at least a quarter of them.

[raygulick]

Some good questions…

[james]

I don’t think this has been discussed much yet.

For WP releases, the update nag is there, but it can be ignored for years. When it is, all the plugin updates are also ignored because the version numbers don’t match.

I don’t follow this part. WordPress/ClassicPress core version is totally separate from plugin versions, and you can update plugins just fine on an older site as long as the plugin is still supported in the older version of core.

The plugin versions and the “stable tag” are another set of version numbers, this time related to the plugin only.

Which versions of WP are supported by a given plugin is yet another set of version numbers, and they have “Requires at least” and “Tested up to” tags in the readme, which makes sense to me. We will probably need to introduce our own tags for these values.

[joyously]

you can update plugins just fine on an older site as long as the plugin is still supported in the older version of core.

This is what I was talking about. The statistics page shows that not everyone updates WP to the latest version (update nag is ignored), so as the plugins continue to evolve to support the more current releases, their “Requires at least” increases, which means that the API won’t return that plugin as needing an update because the Requires is higher than the site’s WP version. (there is only one plugin version served) This gives the illusion of the plugin being up to date when it is not. The WP API just hides the fact that there is a newer version of the plugin, because it is running on an older WP version.

[james]

The WP API just hides the fact that there is a newer version of the plugin, because it is running on an older WP version.

Newer plugin versions probably use functions that do not exist in older versions of WP, so from that standpoint the behavior is correct.

[joyously]

I’m not questioning the policy, just stating what happens. If the update was indicated, the user might actually update WP to get the plugin update.
With CP, it is already known that the versions will likely be incompatible, so serving only one version of a plugin will be a bad thing.

[james]

With CP, it is already known that the versions will likely be incompatible

“likely” is too strong a word to use here - v1 to v2 may break some edge cases, but we won’t be making incompatible changes “just because”.

Previously:

Coding a WP plugin in CP... for newbies

I can’t speak for all future versions, because it depends on what changes go into them. However for ClassicPress v2.x [building new versions of plugins] shouldn’t be necessary.

So far, the only known way that something might break when we move to version 2 is if a plugin or theme requires some part of ClassicPress that we’ve moved out into a core plugin, but we don’t know about that dependency and that plugin gets disabled or removed. This could lead to plugins trying to call functions that don’t exist or don’t do anything any more, for example.

In practice that could mean some plugins will need to add a line like
“Depends on: ClassicPress/core-xmlrpc”
to their docblock in order to continue working with ClassicPress v2. I think we’ll also be able to fill in these dependencies ourselves for at least the more popular plugins.

[invisnet]

I think it’s worth emphasising edge cases - there’s nothing planned that should break anything at all.

[joyously]

@james

“likely” is too strong a word to use here - v1 to v2 may break some edge cases, but we won’t be making incompatible changes “just because”.

Since CP uses semantic versioning, isn’t v2 supposed to be incompatible with v1? Isn’t that what changing the first number means?

[wadestriebel]

1. MAJOR version when you make incompatible API changes

Even the smallest “breaking change” means bumping the major version. This could be anything from an underlying function that a super edge case might be relying on to a full rewrite of the entire code base.

[james]

Exactly. According to the rules of semver we could make a backwards-incompatible change to a couple of functions or behaviors, or we could release ClassicPress v2 as a fork of Drupal instead of WordPress. Doing either of those would be a reason to bump the major version number, but obviously it doesn’t make sense for us or our users to break things that people rely on just because we can.