@westi: Could we add an option in the beta tester plugin to revert to latest stable? With beta tester activated, then deactivated, the version remains the beta version (and beta tester stuff about nightly build stays on Updates screen for some reason). Would be good to be able to revert to stable for troubleshooting purposes.
Recent comments
newtonsongbird on Suggestions Kim Parsell on Core Contributor Handbook Lance Willett on We’re getting very close… Muhammad Abdi on Core Contributor Handbook Maor Chasen on We’re getting very close…
Jane Wells 7:56 pm on June 24, 2012 Permalink
(Even after deleting plugin and associated filed via admin, the Updates screen still acts like beta tester is active.)
kurtpayne 8:00 pm on June 24, 2012 Permalink
How would we roll back database updates?
Mert Yazıcıoğlu 10:05 pm on June 24, 2012 Permalink
By creating a database backup before the activation of the beta tester plugin and reverting back to it on deactivation?
mbijon 12:29 am on June 25, 2012 Permalink
+1 to this idea.
…but the database revert process is a problem: If we create a database backup and revert to it, then there’s a risk that new data will be lost. The extra work isn’t great, but it sounds like every upgrade script might need a counterpart downgrade script.
Marc Hindley 1:16 am on June 25, 2012 Permalink
This feature would be great, not just for beta version, but for any release version, where a plugin might not work after an update, at least for testing purposes. But @mbijohn is right, new data could be lost, so the only way I can think of, is to document the db upgrades and reverse them rather than restoring a backup. That would have the added benefit, that you could select your version to roll back to, or roll back one at a time. It would certainly make upgrading less of a fear, although it might tempt laziness on the part of the plugin developers.
Peter Westwood 9:15 am on June 25, 2012 Permalink
This might be possible
I don’t think trying to do a database backup and revert is going to be simple but it is probably possible to get you back to the latest stable version. I’ll take a look into this.
Alex Mills 6:15 pm on June 25, 2012 Permalink
Just to play devil’s advocate, if people are running betas then they should be capable of backing up their database, etc. and they shouldn’t be running it on a site they care about if not.
By running a beta, you’re taking the risk that something will break.
Jon Brown 9:54 pm on June 25, 2012 Permalink
Would it work to check the database version and only allow rollback if the database version hasn’t been incremented.
I don’t follow core close enough to know if the DB versions get incremented for changes to trunk nightly, or only when there is a new tagged/released version…
Mert Yazıcıoğlu 10:24 am on June 26, 2012 Permalink
Beta Tester Plugin is not supposed to be used on a live site so I don’t think losing the new data should be a concern.
Though, I heard that WordPress Move makes backing up and restoring from a backup process a snap
Shapeshifter 3 12:41 pm on June 27, 2012 Permalink
Alex is correct, and I myself am guilty of running both beta and/or nightly build versions on my live site. Up until now I have not been damaged by the risk, but I frequently update my database on my hosted server and use the bleeding edge nightlies to correct any short-term programming errors or misses.
What I have noticed as a non-developer user is that currently both WordPress 3.4.1 and 3.5 are being developed at the same time. WP 3.4.1 was offered only on the “Point Release Nightlies” but did not actually offer nightly updates. WP 3.5 is offered on the “Bleeding Edge Nightlies”. If I wanted to trim my risks, having the 3.41 version also offered on “bleeding edge nightlies” would help out. If multiple versions of WordPress are being developed at the same time, it seems (and I might be wrong) that having the choice to use either the “point release” or the “nightly builds” for the WordPress versions being developed might alleviate some of the risks for a non-professional user.
I just disabled and uninstalled my beta tester, and Jane is correct in that my site is still in version 3.4.1 RC-1 and informs me that a newer version is available for update.
Alex Mills 4:44 pm on June 27, 2012 Permalink
I run trunk (updated via a “svn up” cron) on my live site as well but I also have automated backups in the event that something goes terribly wrong.
Only 3.5 is actually being developed — the 3.4 branch just receives backported bug and security fixes from trunk (aka 3.5 right now). No new features go into the branches (like 3.4) that need actual testing.
EDIT: Or simply put, development happens in trunk with important fixes being backported to the latest branch.
Shapeshifter 3 5:38 pm on June 27, 2012 Permalink
Thanks for that clarification. I didn’t understand how 3.4.1 and 3.5 were related to each other.