ecko
A package can name the oldest Ecko it is willing to run on:
{
"module": "github.com/me/gps",
"version": "1.0.0",
"entrypoint": "main.ecko",
"ecko": "0.30.0"
}The check happens at import, in the binary that is doing the importing. Someone on an older build is told then, instead of halfway through a function the older binary has never heard of:
package 'gps' needs Ecko 0.30 or newer, and this is 0.29.0.
Upgrade with `curl -fsSL https://ecko.sh/install | sh`, or pin an
earlier version of the package.The message names the package, the line it needs, the version that is running, and the install command. Without the field, the same mismatch failed wherever the missing feature happened to be reached: a complaint about a verb that does not exist, pointing nowhere near the manifest.
Major and minor
0.30.4 asks for the 0.30 line, not for patch 4. A patch release of your package does not start demanding a patch release of Ecko. Comparison stops at major and minor.
Leave the field out when you do not have a floor. Absent means any version, which is the right answer for most packages. A floor set higher than the truth only refuses people whose binary would have run the code.
Who the check can reach
The running binary is what performs it. Ecko 0.30 and later read the field. Ecko 0.29 and earlier ignore it, as they always did. Writing "ecko": "0.30.0" into a package does not protect someone who has not upgraded yet. It protects the next person who imports that package on a binary new enough to understand the field.
The field sits with the rest of the manifest keys on the manifest.