Allow specifying of the minimum required Inko version in inko.pkg
yorickpeterse opened this issue · comments
Description
inko.pkg is used to specify the dependencies of a project. I'd like to extend it to also support specifying the minimum Inko version required to build the project.
The syntax for the rule is require inko X.Y.Z, i.e. require inko 0.15.0, such that a final inko.pkg might look like this:
require inko 0.15.0
require https://github.com/yorickpeterse/inko-optparse 0.3.0 ce2d3df0ffc4be53a83e2ca8e4e1a190f57e837e
Since inko isn't a valid URL, this won't introduce any conflicts with package dependencies.
When running inko build, we then check if the used version of Inko is compatible with the required minimum version. The version check is based on semantic versioning, meaning that e.g. 0.16.0 isn't compatible with a minimum 0.15.0, but 1.2.3 is compatible with a minimum of 1.1.0.
The check should be performed before we parse any Inko source code, and the compiler should terminate with an error if the versions aren't compatible. For dependencies in ./dep we should also verify the version requirements. We need to do this every time inko build runs as one may upgrade an Inko version without running inko pkg sync (e.g. because there's no need for this).
If a package doesn't provide an inko.pkg file, we just build it without performing any checks.
Related work
No response
Should we allow to specify that a module is compatible with multiple major or 0.minor versions, such as Inko 0.15.0 and 0.16.0? If so, how should we format those specifiers?
# Multiple lines (I think this is confusing. Does this require _both_ versions to be installed?)
require inko 0.15.0
require inko 0.16.0
# Multiple fields
require inko 0.15.0 0.16.0
@uasi The version would be the minimum required version, similar to how we do this for packages. This means that if your package is compatible with both 0.15.0 and 0.16.0, you'd simply specify 0.15.0 as the version.
If multiple require inko lines exist in the same manifest, we should produce an error as this is almost guaranteed to be a mistake by the user.
To add to that: looking at our version selection logic for packages, it seems that we treat 0.X and 0.Y as compatible, but following semantic versioning that isn't necessarily the case. While we probably should enforce semantic versioning there (meaning 0.23.1 isn't compatible with 0.24.0), if we do this for the Inko version this can be rather annoying, as you'd have to update your package every 0.X release.
Based on this we should just treat the version as the minimum regardless of semantic versioning, and I'll create a separate issue for handling 0.X versions per semantic versioning.