Why not have rollbacks of non WP.org plugins?

[mkormendy]

Just curious why you couldn't simply

1. store a zip file for every current plugin moving forward
2. every time a plugin is upgraded, zip up the current version before upgrade hook is fired
3. allow any plugin with existing versioned zip files to be rolled back to

I also realize:

• that your plugin ties into the wp.org version history, but there could be a check to see if there are local versions already on the system first?

• that there are some issues with custom db table changes in plugins, but how do you handle those with wp.org plugins that have custom db table changes?

[DevinWalker]

I'm going to tackle this... 3 years later! Hey, better late than never.

[DevinWalker]

I am closing this, as I've decided to make this a pro feature. I realized that to best support this plugin, I have to be incentivized to do so, and creating a pro version has historically been the best way for me to do so.

There is a free plugin that does this currently, called "PlugVer", if you're interested in this feature at no cost. I took a look at the code and how it handles pro versions, and it's not great but it works.