Is it necessary to bump a plug-in’s version if you’re just updating the “Tested up to” attribute?

3 Views

I’ve got a number of plug-in’s hosted on the wordpress.org svn server … with the immenent release of 3.1, I would like to update the “Tested up to” meta data.

There will be no functional changes to the code, just the meta data.

Read More

Is it necessary to change the revision number for such a trivial change?

Post Views: 3

Related posts

Leave a Reply

4 comments

  1. I would only increase the version number if users needed to download the plugin again. The “Tested up to” variable is not used when the plugin is installed, only when people want to install it or want to upgrade. In that case, the information comes from the server anyway, so you don’t need to force a new download of your plugin.

    Of course, if your readme.txt in the trunk directory has Stable tag indicator, you should update the readme.txt in the correct tags subdirectory, otherwise it will get ignored. There is no problem updating a file in the tags directory and not creating a new version, for Subversion it’s a normal directory just like all others, it’s only a convention to use it for tagged historical releases.

  2. I think the other answers have thoroughly explained the arguments in favor of bumping the Tested up to attribute, and I don’t see anything wrong with them. Since no one has mentioned any reasons not to do this, though, I figured I’d play devil’s advocate 😉

    • Tags are intended and assumed to be a snapshot of a program at a given point in time. Editing a tag after the fact violates the conventions people rely on when working with the code. The potential consequences are admittedly minor — if not non-existent — in this specific case, but many people prefer to take a purist stance in situations like these, and keep things 100% clear. This is why some SVN clients will issue a warning when a user attempts to commit changes to a tag.
    • As a potential user of a plugin, if I were looking at the SVN logs and noticed an author making changes to tagged versions, I’d be suspicious that maybe his account had been hacked and someone was trying to inject malware into the latest version, or that the author wasn’t aware of how source control works — and by extension, might not be a very good programmer — which would make me hesitant to download the plugin.
    • You lose some historical data. For instance, if you wanted to come back a year later and track your plugin’s compatibility with core releases, you can’t make an accurate analysis because your data has been corrupted.
    • There’s another mechanism for achieving the same result. The repo lets users vote on whether or not a specific version of a plugin works with a specific version of core. I personally trust that data more than the plugin author’s assertion.
    • I suspect that the motivation for things like this is often the plugin author’s own ego and insecurity; they want to make sure their plugin looks “successful” and gets downloaded as much as possible. I see this kind of behavior a lot among plugin authors and often feel the temptation myself, but I think it’s kind of immature and unhealthy, so I try to resist it.

    My advice would be to relax and leave the tags alone. Just cast your individual vote for “it works” at the repo page — after a round of testing, of course — and leave it at that. If you’re really that concerned about your plugin appearing to be active, then spend your time working on new releases with bug fixes, security/performance/UI improvements and useful new features; don’t waste time worrying about what other people think or how many downloads your plugin got last week.

  3. Well if you’re just updating the readme then I see no reason to increase the version number. If you’re just using the trunk you can do a quick commit to change that one thing and noone will really notice if you’re using tags I think you will need to create a new tag (not 100% not that well versed with svn).

  4. I think it’s safe to say this is a matter of personal choice. Instead of a full version update (e.g. 1.0 to 2.0) you might consider making it a 1.1 release.