3 ms·

Dimensions of Versioning Problem

• compressedgas 2y ago
  The solution is to treat versions as opaque identifiers and encode the information about compatibility between versions of software through a separate database rather than trying to infer it from semantic analysis of the version numbers which are known to not be able to express sufficient compatibility information. The version numbers should only express succession. That is the only thing that should be expected to apply to version number is the "Ordering Comparison Rules". One should not expect that 1.2 can replace 1.1 or that 2 can not replace 1. This compatibility should be expressed through a database in which people with reproducible builds and test frameworks prove that their software which works with 1 also works with 2 or that it does not. The build failures once also reproducible can prove incompatibility. Calculate this out and you get a testable matrix of software package version compatibility that does not depend on interpreting version numbers. The CI systems can automatically fill in the columns of this matrix as new versions of packages are released or even follow the dependencies CI systems and run their own builds automatically once the package's CI system says that the software builds and passes its own tests. In such a design, version numbers become irrelevant and you can use commit ids instead.