Store Lima version in the instance directory

[jandubois]

That way future Lima releases can make decisions about default settings based on the Lima version that created the instance instead of the current instance, and settings for existing instances will not change just because the user updated Lima.

This implements the mechanism I described in #1953 (comment). I'm leaving it in draft mode for now because I'm not sure if the store.MinVersion function is the right way to use the data; I originally wanted to make it an instance method, but then noticed that most location that would need to call it don't have a copy of the instance.

So this PR probably needs to wait until we have a companion PR that makes use of this new mechanism. Or I could drop the MinVersion function for now and leave it for the first PR that will take advantage of the data.

$ limactl ls --format '{{.Name}} - {{.LimaVersion}}'
alpine - v0.19.1
default - v0.19.1-16-gf3dc6ed.m

Either way, feedback welcome!

[jandubois]

@AkihiroSuda Thank you for your feedback; I believe I've addressed all your comments.

I switched to defining a LimaVersionGreaterThan function, so can select default changes based on the last version that still has the old functionality instead of having to guess the next release version number that will have the new default. Still needs to be validated by an actual implementation that uses it though.

if LimaVersionGreaterThan(inst.LimaVersion, "0.19.1") {
   // set new default
}

This code would use the new defaults with any current dev build because v0.19.1-xxx will be treated as greater than 0.19.1.

This should also make it easier to test the new functionality in CI without having to bump the version first.

It does mean though that all instances created by any dev build of Lima after 0.19.1 will be treated as if it was created by the latest build. I think this makes sense, as Lima developers should understand what is going to happen. Let me know what you think!

[jandubois]

Current failure happens because the CI version has no tags, so the version cannot be parsed from the SHA1:

time="2024-01-02T05:59:07Z" level=fatal msg="errors inspecting instance: [cannot parse lima version \"ca7752d\" from \"/Users/runner/.lima/default/lima-version\": ca7752d is not in dotted-tri format]"

Not sure if we should pull tags in CI, so we can then test version-specific changes?

[AkihiroSuda]

Not sure if we should pull tags in CI, so we can then test version-specific changes?

We may pull the tags, but anyway the commit hash string shouldn't cause a fatal error.

[jandubois]

We may pull the tags, but anyway the commit hash string shouldn't cause a fatal error.

The problem is that we won't know the version, so all the version check will return false then. Instead of the newest defaults, we get the oldest ones. Therefore I kind of prefer that this fails in CI instead of silently testing the old values.

We can make this configurable, but it feels like overkill: why do we need to support building outside of a git checkout?

[AkihiroSuda]

The problem is that we won't know the version, so all the version check will return false then. Instead of the newest defaults, we get the oldest ones. Therefore I kind of prefer that this fails in CI instead of silently testing the old values.

I think the version without semver prefix can be just assumed to be "latest", with a warning message.
For the CI, we can pull the tags to attach the semver prefix.

why do we need to support building outside of a git checkout?

Because somebody might be using a package built in that way?

[jandubois]

I think the version without semver prefix can be just assumed to be "latest", with a warning message.

Ok, I think that would work for all practical scenarios; updated!

[AkihiroSuda]

Thanks, is this still draft?

[jandubois]

Thanks, is this still draft?

It is only still draft because of

So this PR probably needs to wait until we have a companion PR that makes use of this new mechanism.

I guess we can also consider merging as-is, and then modifying LimaVersionGreaterThan in the later PR, if it turns out not to be convenient as expected. We did already refine the mechanism based on the discussion here, so I feel more confident now, that it may do the trick as-is.