Add option to install / keep older versions of a plugin

[GitMensch]

It would be good to have an option to install older versions of plugins, too. It happened more than once and is understandable that funky new version X of a plug-in provided bug fixes for b1, b2, b3 and enhancements, therefore you click on "download", just to recognize you like these enhancements but there is a new bug b4 which is much more severe for you - and the plugin manager currently has no way of getting the old version back. A manual backup before a plugin update is something you likely forget when necessary and downgrading from a backup is something not all NPP users can easily do.

The easiest option on the client side would be:

• downloaded pluginlist contains a list of versions, too (including the date - see #29)
• server stores the plugin as zip with version number in

On the GUI side I suggest to add a dropdown with the available plugin versions (date + version) next to the install button + a checkbox next to it "keep version" (no update checks for this plugin are done).

[chcg]

Currently available are two list the dev list and the normal list, which is updated with the dev list with a regular timeframe. So there is a possibility to test new plugin versions before widespread deployment. There is no history provided in the deployed plugin lists. So this would require some kind of history management on server side and either a bigger plugin list deployed to the client or an additional plugin specific download for the history of a plugin.

[GitMensch]

@chcg your description shows: a normal user has no time frame for testing and he may use the plugin manager much later than the release of a plugin. Therefore the only option for "testing" he'd had is if the plugin manager has the option to use a later version, too.

There is no history provided in the deployed plugin lists. So this would require some kind of history management on server side and either a bigger plugin list deployed to the client or an additional plugin specific download for the history of a plugin.

Yes, that's why I said the download list must be changed to include a list of versions, too.

Another option would be to provide the plugins with an internal git client with the following results:

• contra: plugin manager can only do a direct download of the plugin list (text) and would need to ship a minimal git client (not sure how much this would mean in download size of the plugin manager)
• the plugin list would contain the git URL for the file
• the plugin manager would have to do the extra work to fetch the history from this URL
• pro: the history would contain file version, date, actual history
• the server side would "only" change to be a git repo, any tested version would simply be uploaded via git, adding the history entry via git log
• for testing purposes (as there seem to be now) a setting in the plugin manager could include the option to test new versions - these would be fetched from an additional test branch