Plugin manager auto backup old plg on update

Have plugin manager auto backup plg files when updating and add a button next to plugin to roll back to previous version.

 

With PhAzE's plugins when you update them they automatically save the previous version as pluginname.plg.old in the plugins dir. There is also a button in the settings of the plugin to roll it back to the previous version. It would be nice if these features were implemented in the main plugin manager. Then you could easily rollback an updated plugin you had issues with with a "Downgrade" button next to the plugin entry.

I have to say I like this too, strongly recommend it, not a critical item though, but highly desirable.  It would make auto updates more palatable for many.

 

I do understand you may have to reboot afterward, in some cases.  And it is also possible that the downgrade won't work in some cases, if the upgrade makes changes that are not backward compatible.

 

Implementation could be either with the *.old method mentioned above, or like the 'plugins-removed' folder method you are using now (move them to plugins-upgraded for example).

This would definitely be a nice feature => I've used the equivalent in Windows many times over the years for drivers when an updated driver causes issues.

 

I have to say I like this too, strongly recommend it, not a critical item though, but highly desirable.  It would make auto updates more palatable for many.

 

I do understand you may have to reboot afterward, in some cases.  And it is also possible that the downgrade won't work in some cases, if the upgrade makes changes that are not backward compatible.

 

Implementation could be either with the *.old method mentioned above, or like the 'plugins-removed' folder method you are using now (move them to plugins-upgraded for example).

Awesome idea.  CA can do it in autoupdates, but ideally should be done through the plugin manager.

 

But, as far as roll-backs, there is an initial problem.  If the update came through an auto-update, then rolled back, you'll have to disable autoupdates on the plg in order to keep the rollback installed.  If you forget, its just going to update again.  And I'm probably not going to implement a fullblown update manager system unless dynamix supports rollbacks to make the disabling bit automatic.

Another example of where backups of the .plg file would have come in handy:  http://lime-technology.com/forum/index.php?topic=39985.msg501278#msg501278  (and no notification within the thread, the OP, or in the changelog for the plugin itself)

I can see a lot of complexity in this scheme.  In order to rollback a plugin, the newer version would probably have to be removed and then the previous version installed.  I can see where some plugin settings would be lost in this process because they are removed in the plugin removal process.  I've also seen some plugins that don't do a good job cleaning up after themselves and the residue left will cause problems.  i.e. in emhttp package removal/installation/updating.

 

Maybe a better approach for now would be a switch in CA that would allow notification of updates as it does, but not actually do an update without user intervention.

 

Wow, I think I just passed the buck on to Squid.  Sorry Squid.

Wow, I think I just passed the buck on to Squid.  Sorry Squid.

Gee, thanks....  EDIT:  Isn't that what dynamix already does?  Informs the user there's an update but doesn't actually do anything about it?

 

But I'm going to pass it back to the plugin manager, because its irrelevant how the update actually happened.  (Like with preclear I posted above)...  Regardless of if CA autoupdated it, or if the guy manually checked for updates, or if people took gfjardim's advice advising that there was an issue and to update the plugin and manually did it, there was no warning that the plugin was deprecating 6.1.x anywhere and if it was perfectly functional otherwise, the backup of the .plg file would have now saved the day, rather than forcing the guy to manually modify a plg to grab an older version.

 

And, I think that it's perfectly reasonable to expect a user to at the very least have to restart their server to accomplish a rollback.  (And right now at least all I want out of plugin Manager is to just backup the .plg).  I agree that the issues involving a roll-back button are complicated to say the least, and would be a learning stage for everyone involved.

 

I realize that LT has now deprecated 6.1.9, and might not care about this particular example, but it does illustrate perfectly when a backup of the plg would have come in handy...

Wow, I think I just passed the buck on to Squid.  Sorry Squid.

Gee, thanks....  EDIT:  Isn't that what dynamix already does?  Informs the user there's an update but doesn't actually do anything about it?

I think you're right.  CA has spoiled me.

 

But I'm going to pass it back to the plugin manager, because its irrelevant how the update actually happened.  (Like with preclear I posted above)...  Regardless of if CA autoupdated it, or if the guy manually checked for updates, or if people took gfjardim's advice advising that there was an issue and to update the plugin and manually did it, there was no warning that the plugin was deprecating 6.1.x anywhere and if it was perfectly functional otherwise, the backup of the .plg file would have now saved the day, rather than forcing the guy to manually modify a plg to grab an older version.

 

And, I think that it's perfectly reasonable to expect a user to at the very least have to restart their server to accomplish a rollback.  (And right now at least all I want out of plugin Manager is to just backup the .plg).  I agree that the issues involving a roll-back button are complicated to say the least, and would be a learning stage for everyone involved.

 

I realize that LT has now deprecated 6.1.9, and might not care about this particular example, but it does illustrate perfectly when a backup of the plg would have come in handy...

 

Keeping a backup is not a bad idea in cases like this.  Maybe just keep a copy and let the user sort it out and do a reboot to refresh everything.

 

EDIT: Does installplg allow installing an older version than the current version installed?  I've never tried.

The plugin authors and plugin manager needs to offer multiple version support. For a working model take a look at how NuGet works on http://nuget.org/ . The package manager needs to allow explicit version installation.

EDIT: Does installplg allow installing an older version than the current version installed?  I've never tried.

You have to give it the full path to the appropriate .plg, so yes it will allow you to.  But, I *think* you'd have to do a removepkg first to get rid of the existing txz prior to an installplg that has an older txz referenced.

 

But, restore the .plg backup, reboot, and everything will be back the way it was.  (except if there were major setting changes, etc - but that's a different story, and can't be helped)

EDIT: Does installplg allow installing an older version than the current version installed?  I've never tried.

You have to give it the full path to the appropriate .plg, so yes it will allow you to.  But, I *think* you'd have to do a removepkg first to get rid of the existing txz prior to an installplg that has an older txz referenced.

 

But, restore the .plg backup, reboot, and everything will be back the way it was.  (except if there were major setting changes, etc - but that's a different story, and can't be helped)

 

I see what you mean.  Kind of like the Windows restore capability.  Sort of like this:

- Click on a restore previous plugin to copy the previous version back.

- Reboot to get back to were you were.

- Ignore the update plugin notice, or have the ability to block updates to a particular plugin.

 

Would CA be better setting certain plugins to not update, rather than setting those plugins to update?

The plugin authors and plugin manager needs to offer multiple version support. For a working model take a look at how NuGet works on http://nuget.org/ . The package manager needs to allow explicit version installation.

I'm going to state that at least on my end that it isn't going to happen.  I support one version and one version only.  Latest release.  Mind you, I also jump at any and all bugs.  Additionally, I also make sure that the plugs adjust themselves to different OS versions for a good long time.  CA still supports 6.1.0+ (and adjusts itself accordingly), and didn't drop support for 6.1RC/Beta and 6.0 until 6.1.9 was released.

Would CA be better setting certain plugins to not update, rather than setting those plugins to update?

That's how it does work.  Defaults are to not update anything but CA / FCP (since they are mine, I feel justified in setting their default update status to what I feel is correct (especially on CA since its a very big moving target and constantly moving ahead, and coupled with the evolving xml schema, things just don't work right on CA if you go back too far) - but do allow you to opt out of it)

 

But we're drifting off topic.  Backups of .plgs aren't a CA issue, because it doesn't matter HOW the update got in.  There are times when you want to rollback, and its a royal pain to do it since the plugin manager doesn't create the backups.

The plugin authors and plugin manager needs to offer multiple version support. For a working model take a look at how NuGet works on http://nuget.org/ . The package manager needs to allow explicit version installation.

I'm going to state that at least on my end that it isn't going to happen.  I support one version and one version only.  Latest release.  Mind you, I also jump at any and all bugs.  Additionally, I also make sure that the plugs adjust themselves to different OS versions for a good long time.  CA still supports 6.1.0+ (and adjusts itself accordingly), and didn't drop support for 6.1RC/Beta and 6.0 until 6.1.9 was released.

 

Agreed. I have enough trouble supporting one version.  Let alone multiple versions.

I'm not implying that multiple versions are "supported" by the developer. The developer just needs to make sure their releases are versioned and that those multiple versions are hosted online so the users can rollback if desired by using the package manager.

 

How it works for NuGet is each release is versioned and the nuget server that hosts the packages support hosting multiple versions of the same package at the same time. The package manager then displays the various versions available to the user in advanced mode. The default mode for updates and installation is latest version, but the user can override that to install specific version if its still on the hosted package server.

I'm not implying that multiple versions are "supported" by the developer. The developer just needs to make sure their releases are versioned and that those multiple versions are hosted online so the users can rollback if desired by using the package manager.

 

How it works for NuGet is each release is versioned and the nuget server that hosts the packages support hosting multiple versions of the same package at the same time. The package manager then displays the various versions available to the user in advanced mode. The default mode for updates and installation is latest version, but the user can override that to install specific version if its still on the hosted package server.

fair enough, but TBH I would still vote against it.  In my mind, easy availability of previous versions implies support

 

And that system would require a rather large overhaul to the plugin manager for what really amounts to supporting edge case issues.  A backup of the plg is a simple one line addition to the code.  (Maybe tomorrow I'll find in plugin manager where to do it and give LT a PR on it).  The roll back button isn't required per se.  Keep it a manual operation where you copy & paste the plugin file to roll back.

Yes, that is a bit of work for the plugin manager but thats whats required if you want it done right.

 

Sure the plugin manager can continue to do it wrong and have multiple workarounds in places that shouldn't have to deal with plugin manager shortfalls, like Community Applications.

 

A single backup of a package isn't enough especially if a plugin author pushes several releases out in the time between when a "bad" update is pushed and when it's noticed by the user especially if "auto-updates" are enabled. So how many backups do you want to support in CA? Or do you want to disable auto-updates?

Yes, that is a bit of work for the plugin manager but thats whats required if you want it done right.

 

Sure the plugin manager can continue to do it wrong and have multiple workarounds in places that shouldn't have to deal with plugin manager shortfalls, like Community Applications.

 

A single backup of a package isn't enough especially if a plugin author pushes several releases out in the time between when a "bad" update is pushed and when it's noticed by the user especially if "auto-updates" are enabled. So how many backups do you want to support in CA? Or do you want to disable auto-updates?

Who said we're talking about autoupdates?  Your scenario plays through the same for people who update the plugins when the notification comes through.  This req is about a one-line addition to support edge case scenarios.

 

The OP had a valid suggestion regardless of the method that the update comes through on.

 

As to how many backups to keep, I think that LT pretty much established the precedent on that, since they themselves make a backup of the OS when updating.  Realistically, there should be more than a single one, but you do have to start somewhere.

 

Yes, that is a bit of work for the plugin manager but thats whats required if you want it done right.

 

Sure the plugin manager can continue to do it wrong and have multiple workarounds in places that shouldn't have to deal with plugin manager shortfalls, like Community Applications.

 

A single backup of a package isn't enough especially if a plugin author pushes several releases out in the time between when a "bad" update is pushed and when it's noticed by the user especially if "auto-updates" are enabled. So how many backups do you want to support in CA? Or do you want to disable auto-updates?

Who said we're talking about autoupdates?  Your scenario plays through the same for people who update the plugins when the notification comes through.  This req is about a one-line addition to support edge case scenarios.

 

The OP had a valid suggestion regardless of the method that the update comes through on.

 

As to how many backups to keep, I think that LT pretty much established the precedent on that, since they themselves make a backup of the OS when updating.  Realistically, there should be more than a single one, but you do have to start somewhere.

 

I only mentioned autoupdate because of the higher likelihood of being caught by naughty developers with bad updates.

 

As for the backups ... perhaps the currently installed version of the plugin (plg) can be moved into a backup subdirectory that has the plugin name and version number in it, so that way it inherently supports multi version backups before upgrading? Should be easy to do since the plg file has the version in it, right? So its just a matter of how the backup subdirectory name is built up.

As for the backups ... perhaps the currently installed version of the plugin (plg) can be moved into a backup subdirectory that has the plugin name and version number in it, so that way it inherently supports multi version backups before upgrading? Should be easy to do since the plg file has the version in it, right? So its just a matter of how the backup subdirectory name is built up.

Exactly what my PR to LT does   

Yes, that is a bit of work for the plugin manager but thats whats required if you want it done right.

 

Sure the plugin manager can continue to do it wrong and have multiple workarounds in places that shouldn't have to deal with plugin manager shortfalls, like Community Applications.

 

A single backup of a package isn't enough especially if a plugin author pushes several releases out in the time between when a "bad" update is pushed and when it's noticed by the user especially if "auto-updates" are enabled. So how many backups do you want to support in CA? Or do you want to disable auto-updates?

 

Including rollback support in the plugin manager is only half of the story. It really depends on the plugin itself whether a rollback is possible or not.

 

E.g. all of the Dynamix plugins maintain a single version. AKA the latest version, which makes it impossible to do a rollback once the newer version is installed.

 

Furthermore plugins may make irreversible changes, e.g. database conversions or files relocation, which can not be undone in a rollback scenario.

 

 

Furthermore plugins may make irreversible changes, e.g. database conversions or files relocation, which can not be undone in a rollback scenario.

And that caveat has already been discussed...

Yeah, thats why I indicated in earlier post that plugin creators would need to host multiple versions along with the plugin manager supporting multiple versions. Yes, there will always be issues between upgrading and downgrading, but those are fringe cases of fringe cases. The only way for plugins to reach the same maturity level of dockers is to support explicit multiple versions existing.  This works with dockers and it works with NuGets, so it should work for plugins too. Naturally the developer would only ever provide user support for the latest version.

 

I think the PR changes that Squid did is enough to satisfy the majority of issues caused by naughty developers with bad updates.

 

Take for instance the situation where the preclear plugin was changed without concern for users still on 6.1.9, the user updates the plugin and now nothing works at all. They can now uninstall the bad version and do an install of the previous version manually. Thats much easier for the users than trying to get the developer to provide a solid fix.

 

 

Take for instance the situation where the preclear plugin was changed without concern for users still on 6.1.9, the user updates the plugin and now nothing works at all. They can now uninstall the bad version and do an install of the previous version manually. Thats much easier for the users than trying to get the developer to provide a solid fix.

Actually investigated further, and preclear_disk will still operate under 6.1.9 (it'll just always show an update available).  BUT, should the user for some reason need to uninstall preclear to diagnose an issue, then it won't allow you to install it period. And that's where the backup would be of immense use.

 

As bonienl stated (and we've already stated prior), the possibility of a rollback of a .plg working is not a 100% given, depending upon what the updated one did.  But, its a dirt simple change to make the backup with no operational consequences and if it works when needed then the user is ahead.  If it fails when needed, then the user is in the same boat as they are now.  To me its a no-brainer.  Just have to see now whether LT accepts the PR.

 

The only way for plugins to reach the same maturity level of dockers is to support explicit multiple versions existing.  This works with dockers and it works with NuGets, so it should work for plugins too.

Technically, the majority of plugin authors (with the notable exception of bonienl) do support the same method of installing previous versions.  Most plugins install a "versioned" source file that is selected within the .plg

 

 

But no-one including myself is going to expend any time and energy doing a major overhaul to the plugin management system to support rollbacks, because ultimately its going to remain a very little used feature.  A backup of the .plg file is about the only thing possible to do that will work most of the time and costs nothing to implement.

I just tried and confirmed the plugin manager won't install a previous plg version currently.

 

Also if the plugin is installed with a versioned txz then using upgradepkg --install-new will remove the existing plugin files and install the package. Doesn't matter if version is old or new it will remove existing files.