Minimum-Upgradable-Version

The Minimum-Upgradable-Version field indicates the minimum version that an installed package about to be upgraded can be. If the installed version is smaller, then the upgrade cannot happen.

With time, when maintaining a project, it happens that upgrade scripts are necessary to fix things that have changed from the previous version. For example, if you maintain a file with a specific format in plain text, and one day decide to convert that file to XML for additional flexibility, then the upgrade script can take up the job of converting that text file to XML1. In theory, this works great but requires the project maintainer to run that check forever and ever because anyone using an older version of the package may still have the file in text format.

To break up from such problems, the versioning system can be used with the Minimum-Upgradable-Version mechanism. Say that our project maintainer was making use of that text file format in all versions up until version 1.15. In version 1.16 the new format appears and the upgrade script takes care of the conversion for the project (that means no such conversion is necessary in the software!) The project maintainer continues to make upgrades up to version 1.23. At that point, he stops on version 1.x and starts working on version 2.x. In that new higher version, he wants to remove the text to XML conversion mechanism from his upgrade script because it is cumbersome to keep it there. Plus new users do not need it... and maintaining it with such very old text files does not make much sense anymore (after 2 years or so...)

The upgrade of version 1.23 to version 2.0 will work like a charm since the file format is already as required. However, upgrading version 1.9 to version 2.0 would fail. That file would remain in text and 2.0 expects the file format to be XML no matter what.

In this sort of situation is where the Minimum-Upgradable-Version comes in. In our example, the package version 2.0 would include this field:

Minimum-Upgradable-Version: 1.16

This means any user who has version 1.16 or better will be able to upgrade to version 2.0 without any trouble. However, somehow who has version 1.9 would be asked to first upgrade to at least 1.16 before the 2.0 upgrade can be applied. This way all the scripts that were necessary to upgrade versions before 1.16 can all be dropped from the 2.0 scripts.

• 1. It is of course not unlikely that this will be done by the tool when loading the file: detect the format and parse the file one way or the other depending on the result. This is more for the sake of the example. Such changes are in most cases applied to configuration files where some parameters may have become obsolete or considered to be security issues.