[bug] New lockfile content without new lockfile version about conan HOT 7 CLOSED

I am happy with the answers I have got and have voiced my opinion on how I believe this should work as a consumer, it is up to you now if you decide to change it in the future. :) Thanks!

from conan.

Hi @aander80

Thanks for your report.

Should that not be bumped to 0.6? This is also not changed in the docs (e.g. https://docs.conan.io/2/reference/commands/lock/add.html).

In principle this is not a bug. The addition of config_requires should be forward and backward compatible, not breaking. We use the version changes only to represent incompatible lockfiles.

from conan.

I was expecting the version to adhere to semver (with patch dropped) so that a new entry would fall into the "new feature" category and hence require a minor version update. Not a bug per se, but I would label it "unintended behavior" from a consumer perspective, but perhaps this is common for lockfiles and schemas in general?

from conan.

Thanks for the feedback.

The problem is that Conan lockfile loading code contains:

 if version and version != LOCKFILE_VERSION:
            raise ConanException("This lockfile was created with an incompatible "
                                 "version. Please regenerate the lockfile")

That means that changing the version in any way will automatically raise errors in previous Conan versions, which for this case it is too much, as commented above, the change is not breaking, and previous Conan versions can perfectly use a lockfile generated with Conan 2.2

So not unintended behavior, this is intended and known, we didn't want to bump the version because it would be creating some unnecessary pain to users, and we prioritize that over conceptual correctness of the version definition.

from conan.

Alright, that is a good explanation! Given the current code-base, I agree that keeping compatibility for current commands is more important. Had the "major" version in the lockfile been a 1, I would have still thought it to be clearer as a consumer of conan if a change would have been made alongside a minor version bump (and that conan itself would have supported it), but since the major version is 0 I guess it is a different story.

Speaking of major version 0, do you still see the current lockfile format and behavior as experimental, or is that considered stable now in conan 2? From what I have tested so far, it is very good compared to conan 1.

from conan.

Speaking of major version 0, do you still see the current lockfile format and behavior as experimental, or is that considered stable now in conan 2? From what I have tested so far, it is very good compared to conan 1.

The functionality of lockfiles in Conan 2 is indeed much better than in 1, and as a result of the much simpler lockfile file format and contents, I'd expect that the file will be much more stable too, I don't think that we will be breaking it in future releases. Still we didn't decide yet to declare it "1.0", there are some research to try to put lockfiles inside packages too to be used at graph resolution time, like shrinkwrap in NPM, so we might wait until that.

from conan.

Thanks for the feedback! We will certainly take into account the lockfile version stabilization for future changes

from conan.