More information to enable making plugin update decisions on plugin stats tab

[galbaras]

When making update decisions, the factors that come into play are:

1. How long ago the latest version was released
2. How many people already use it
3. How these people rank its quality (with automatic core updates, we can safely ignore all but the latest WP versions here)

The new "active versions" display is a great way to help visualize things. To make it even greater, can you please show the actual number of installations for each version (not just the percentage), the date it was released and the community score for the current WP version?

I'd say this will make it a perfect way to decided at a glance whether the outstanding plugin version should be used.

In fact, with this being displayed, I would not bother with the graph, so you might as well make the block chart vertical and give it as much room as you need.

Thank you,
Gal

[galbaras]

Sorry, I've just had another look at the active versions display and there are 2 other useful points to make:

1. The graph only shows 2nd level version numbers, but some plugins have 4 levels, e.g. shareaholic is now on version 7.6.1.0 and the graph shows 7.6

2. (slightly off topic) The "works" or "broken" score shows "works" with 3 positive votes and 1 negative votes, which seems like too low a ratio to be safe

Cheers,
Gal

[dd32]

Although some plugins use x.y.z.?, we'll only be supporting these stats on x.y for ghee foreseeable future.

The main reasons behind this are

• the majority of plugins use x.y.z,
• grouping on major versions is granular enough for most authors I spoke to (including several who use x.y.z.?)
• grouping by different depths for different plugins requires a significantly different stats approach that couldn't be used(due to generation time)

Although the version usage numbers can be inferred for most plugins from the active number, that's not really useful as a plugin grows (since it becomes 10,000+/100'000+/500,000+/1+ million).

For now this is a wontfix, but future iterations might change things.

[galbaras]

Dion, the focus on plugin developers here seems odd. After all, the plugin directory is for those who USE WordPress, not those who write the plugins. If users can't make update decisions due to the way changes are displayed, the vast majority of those who visit the plugin directory are being ignored.

7.6 is not x.y.z. It's only x.y, so your first reason isn't actually in effect.

To make things more manageable, rather than reducing the resolution, you could reduce the number of versions being shown. If something is already at 7.6.1.0, nobody needs to see v3.2.4.5 anymore. Again, the display should not be there for sentimental or historical value. It should be practical.

Willfix? Please?

[Otto42]

To make things more manageable, rather than reducing the resolution, you could reduce the number of versions being shown.

For plugins, we're not actually storing the data at that level. For speed and size reasons, we're storing "3.8" not "3.8.1". Actually changing this would be a much more difficult task than you think. The storage requirements balloon way up very quickly, and the method by which we query that data to produce those numbers would need to be completely reworked from the ground up.

It's a *lot* of data, in other words. This sort of version reduction approach allows for that data to be reduced to manageable sizes for the time being while still providing useful information for the majority of plugin developers.

Realistically, plugin authors should be using the major.minor.revision scheme anyway. There should never be any reason to not update from 1.0 to 1.0.1. If there is a change which is "breaking", then the version should reflect that outside of just the revision number.

[galbaras]

Thank you for clarifying this and I get that there are limits to the investment in any feature.

Still, the plugin directory should be designed for plugin users, who nowadays need to update frequently and are faced with quite a lot of dud releases. So far, Dion talked about plugin authors and you talked about technology/resources, and my point got lost somehow.

Plugin authors should play nice and stick to standards. As a community, we can influence how they act using our ratings, forum threads and what we choose to download. To me, the wordpress.org site should facilitate this community moderation and the users will do the rest. Without tools, many will find the effort to big to participate.

[Otto42]

Plugin authors should play nice and stick to standards. As a community, we can influence how they act using our ratings, forum threads and what we choose to download. To me, the wordpress.org site should facilitate this community moderation and the users will do the rest. Without tools, many will find the effort to big to participate.

We are. This is part of that. It's a different view, certainly, but getting everybody on the same page is a big, long term, job.

[galbaras]

I get that this is not a centralized-control system and that some things take time to change. I have a lot of respect for the people who give their time to making the system better. This is my way of giving back.

Not sure how, but I'm pretty sure that to make WordPress sites (blogs, not wordpress.org) the most stable and hassle free, unless there is strict quality control in the plugin repository, the next best thing is to provide quick and reliable ways for site owners to make update decisions. I'm hoping that's easier to do.

Maybe this should not be a response to the plugin usage graph, but it's still important, so can you suggest some other way of pushing it through?

[Otto42]

At this time, we are not going to implement this. We do not have the data for minor versions and are not storing it, and we will not be releasing actual install counts because the data gathering mechanism is not perfect and the numbers are not exact. We believe the percentages are accurate, however exact numbers are tricky and prone to error.