Do "forgets" activated plugins after every update

Please set the importance higher than "Low" because this is a major usability bug.

Not really. You don't upgrade every day, so it's hardly a usability bug. We
can't always guarantee that old plugins will work with new releases, and it
this case we could guarantee that they would not work, so remembering
completely broken plugins is a much bigger bug, don't you think?

--
--Alex Launi

Fair enough. Disregards all the non-official plugins, I suppose Official plugins settings should be retained no? It is "OFFICIAL" after all. If you release new version of Do but there is no working official plugins for it (naked Gnome-do), it doesn't make any sense for me at all.

No, if the Do API changes, your old plugin STILL won't work. Official just
means it will be maintained, nothing else. We are not fixing this as its not
a bug. If the ABI doesn't change then old plugins will be remembered, but
that has not been the case so we will continue to 'forget' broken plugins.

--
--Alex Launi

If this behavior annoys you, I highly suggest that you use the release
that comes with your distribution. If you are drinking from the
firehose, don't complain when you get splashed.

I understand now why this behavior exists, but I'm wondering if there couldn't be some way to auto-detect whether the plugins would work. For example, there have been a series of updates lately. The first one did appear to be major, but the other ones seemed to be smaller. In fact, the list of available plugins was identical between updates--at least for the plugins I care about. So the fact that I could simply re-enable them suggests that whatever API changes were made didn't affect those particular plugins.

I don't know C#, but something like the following wouldn't be too hard in Ruby or Python. Maybe C# is capable of something like this:

1. On the first run after the version number changes, Do introspects each plugin to discover whether the API calls it makes are still valid (this assumes that incompatible API changes result in changes to the API method names).
2. If the inspection passes, do nothing.
3. If it fails, disable the failing plugin(s) and pop up a dialog explaining that plugins x, y, and z are incompatible with the current version of Do and have thus been disabled.

I think that such an approach would be better from a usability perspective while still addressing API changes.

I understood your points. I apologize for my callous behaviour. Keep up the good work! :)

Some of this is actually our fault; the plugins path changes more
frequently than the ABI (for example, 0.7.99 and 0.8.0 had the same ABI,
but different plugins directories). This is bug 321652.