Versioning policy (Windows installer in-place updates)

[Marsu42]

Looking at http://www.imagemagick.org/script/changelog.php the version numbers of im seem completely random - esp. when a change of 7.x.y to 7.x.y+1 occurs or when it's just a 7.x.y-z to 7.x.y-z+1 step.

The annoyance is that with a minor version number change, the Windows installers refuse to do an in-place update but you have to uninstall the old version manually. I guess this would make sense to have incompatible versions running along side each other - but for odd minor version bumps this doesn't make sense at all to me.

I know you devs would be simply running the git version, but from a user's point of view it would be nice if bugfixes would be marked with -z steps and only updates that could break something (and therefore deserve to install the new version side by side) get a .y step. Then reserve the .x updates for big publicity updates with press releases. Just my 2ct after manually uninstalling old .y versions so many times :-\

[dlemstra]

We don't use semver at the moment and we don't have plans to go towards this. Our z will go to 10 en then we will increase x and reset z back to zero. But I can take a look though why our installer cannot upgrade the current installation. This should be possible with InnoSetup.

[Marsu42]

This should be possible with InnoSetup.

Thanks for looking into it, the current installer oddities don't make im appear like the excellent software it is.

At the same time, could you please address another tiresome problem: When in-place updating the Windows installation, the setup asks if it should overwrite a number of files (see list below) and you have to go in clicking "Yes". Are these really all user-serviceable files that should be protected against accidental overwrite (I know delegates.xml is) ... but is the user really likely to change sRGB.icc?

Anyway, imho any user-serviceable files shouldn't be modified inside the installation directory tree at all, that's Win3.1 style at best. They should be located somewhere in %appdata% - i.e. if you want to modify delegates.xml, you have to copy it there, and if it's found there it'll be used instead of the distribution one in the installation dir. That would take care of the overwrite prompts, too.

* colors.xml
* english.xml
* locale.xml
* log.xml
* magic.xml
* mime.xml
* quantization.xml
* configure.xml
* ImageMagick.rdf
* delegates.xml
* policy.xml
* sRGB.icc
* thresholds.xml
* type-ghostscript.xml
* type.xml
* coder.xml