Following up on @scribu‘s post with further rationale and the 31compat tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.).
The many problems. When plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party upgrades were introduced in 2.8, the activation hook fired for them. The deactivation hook did not. This was inconsistency number one.
When bulk plugin upgrades were introduced on the Tools > Updates screen in 2.9, the activation hook did not fire (during the bulk upgrade). This was inconsistency number two.
Bulk plugin upgrades were given greater prominence in 3.0, with the Updates move to under Dashboard, and a new bulk action on the plugins screen. This made the second inconsistency far more prominent.
Additionally, activation hooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. could always fire on activation, because that has to be done through the admin (and super admin), but updates don’t. Updates done manually (including SVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.) was just one more instance where we may not have been firing updates. This was inconsistency number three.
We felt that the proper fix was to prevent the activation hook from firing on any upgrades, bulk or not, as this was not intuitive. Sorry if your plugin relied on this undocumented behavior.
The theory behind the right way to do this. The proper way to handle an upgrade path is to only run an upgrade procedure when you need to. Ideally, you would store a “version” in your plugin’s database option, and then a version in the code. If they do not match, you would fire your upgrade procedure, and then set the database option to equal the version in the code. This is how many plugins handle upgrades, and this is how core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. works as well.
The right way to do this. I would do what many other plugins do and do the upgrade procedure as I described, and as Peter and Andy described in the previous post.
Further reading. You can read more about this issue, on ticket Created for both bug reports and feature development on the bug tracker. #14915.