Opened 16 years ago
Closed 16 years ago
#1946 closed defect (fixed)
Plugin update not working as expected
| Reported by: | stoecker | Owned by: | framm |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | Core | Version: | |
| Keywords: | plugin update process | Cc: |
Description
When updating plugins the loaded internal number is used as references. This has some side effects:
a) A second call to update tries updating the same files again.
b) Disabled plugins are not updated at all.
Solution:
JOSM should base its update process on the on-disk version of plugins (NOTE: For windows the download directory must be taken into account also).
Attachments (0)
Change History (4)
comment:1 by , 16 years ago
follow-up: 3 comment:2 by , 16 years ago
The point b) is "disabled by selected plugins". This occurs, when JOSM detects an error in loading a plugin.
Your comment is a duplicate of #1903.
But I found an addition. Deleting unused plugins should be possible.
comment:3 by , 16 years ago
| Keywords: | plugin update process added |
|---|
Replying to anonymous:
The point b) is "disabled by selected plugins". This occurs, when JOSM detects an error in loading a plugin.
Not sure, what you want to tell with this. At least I didn't catch your point.
Your comment is a duplicate of #1903.
I disagree. While it is about a JOSM enhancement related to plugin updates, the goals are different. What, if plugin numbers are matching but the new plugin code is buggy? That's why I say, we need a backup-copy of older, know-to-work stuff. I broke my working installation some times, too often, already and got quite paranoid about updating JOSM and plugins.
But I found an addition. Deleting unused plugins should be possible.
When? On de-activation? Well it depends. Dialup connection users would wish to have a chance to decide not to delete something they could possibly use again in the future.
I don't see, why b) is a problem at all. In fact on re-enabling a plugin JOSM now (seen in revision 1198) asks with clear wording, if it should use the locally stored or load a fresh version of that plugin.
But there is another thing related to plugin update that I found important:
You can just update plugins all at once or none. If you update one of the plugins to an non-functional new version or switch as the same user between JOSM revisions I see no chance right now to revert an update. There should be a timestamped backup-copy of the old plugin or at least of the whole .plugins directory before the update, so you can downgrade plugins any time later, i.e. in case of bad luck with the new version or if you want to revive an older JOSM revision.