You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 3, 2018. It is now read-only.
Currently, the root lock file plays a role in solving by providing the first version to a versionQueue on initial creation (if the project in question isn't marked for a version change). Putting that version on top of the queue means that we'll attempt solutions with that first - that is, unless the version has to change, it won't. This is how we achieve basic version stability.
This same general concept could easily be extended to the lock data from deps, allowing us to first attempt solutions that maintain the versions used by deps (though only after the version specified by the root lock, of course). Basically, these would only come into play if the root lock's version becomes unsatisfiable, or if there's no root lock at all.
For the Go ecosystem as it exists today, that latter case really matters. With all the tooling out there (particularly godep) that provides nothing more than a locked revision, converting those into lock data that can be used to express a 'preference' will allow us to transparently maintain stability of transitive deps. Basically, it lets us have a default case where the dependency relationships remain as they are.
The text was updated successfully, but these errors were encountered:
Currently, the root lock file plays a role in solving by providing the first version to a
versionQueue
on initial creation (if the project in question isn't marked for a version change). Putting that version on top of the queue means that we'll attempt solutions with that first - that is, unless the version has to change, it won't. This is how we achieve basic version stability.This same general concept could easily be extended to the lock data from deps, allowing us to first attempt solutions that maintain the versions used by deps (though only after the version specified by the root lock, of course). Basically, these would only come into play if the root lock's version becomes unsatisfiable, or if there's no root lock at all.
For the Go ecosystem as it exists today, that latter case really matters. With all the tooling out there (particularly godep) that provides nothing more than a locked revision, converting those into lock data that can be used to express a 'preference' will allow us to transparently maintain stability of transitive deps. Basically, it lets us have a default case where the dependency relationships remain as they are.
The text was updated successfully, but these errors were encountered: