Plugins don't always tag their latest releases #15
Description
Problem
~33% of WordPress plugins (~20k) don't have an SVN tag matching their latest release. This means their newest version can't be served as a proper Composer package.
WordPress officially recommends tagging every release and is working toward disabling trunk as a release mechanism
Warning
WPackagist serves the latest untagged version as a "stable" tagged release, which can result in unexpected plugin updates. For example, a plugin author could push breaking changes to trunk without bumping the version number, and composer update would pull those changes in as if they were the same stable version.
What we've done
- Untagged Plugins page page — lists all affected plugins with links to request tagging on the plugin's support page
- Detail page warnings — when a plugin's wp.org version doesn't match any tagged SVN release, the detail page shows a warning with the
dev-trunkinstall command dev-trunkinstalls (Split dev-trunk into ~dev.json for proper SVN revision locking #65) — every package now has adev-trunkversion available:composer require wp-plugin/example:dev-trunk- Revision pinning (Pin dev-trunk to SVN revision and remove unpinnable dist #69) —
dev-trunkis pinned to a specific SVN revision (e.g.trunk@3478537), socomposer installfrom a lock file is actually immutable. This is an improvement over wpackagist's approach which uses?timestamp=cache-busting but still serves whatever trunk currently contains.
What plugin authors should do
Tag your releases in SVN.