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
Eco needs a model of how it knows when a library causes a breaking change, because all automated processes must be correct or have known error cases, which might be hard to figure out from the source. This issue is for tracking the model and proofs based on the planned design.
The definition of "breaking change" used here:
Does not include dependency version conflicts, when a library has multiple dependency paths to versions of same library that differs in the first non-zero number.
Includes a breaking change caused by the existence of a newer version of the library that differs in the first non-zero number.
In summary, when a library is listed in the extract info, it is known whether the library will cause a breaking change or not:
might_cause_breaking_change(library) -> knowledge
([is_listed_in_extract_info] [:] true) -> [:] known
If a library is not listed in the extract info, it is not known whether it will cause a breaking change. It might be possible to detect whether it causes a dependency conflict, which is why the definition of "breaking change" does not include dependency conflicts. By design this desirable because:
Some libraries are stable and have stable dependencies. We are not interested in extracting information in this case.
A project might choose to run on a specific version for a time period to speed up development. We are interested in the breaking change information related to a localized part of the ecosystem.
The known error case is when a library listed in the extract info has a dependency that is not listed. In a such case a breaking change is not detected. However, if one of the listed libraries updates its dependencies, a potential dependency version conflict might be detected.
Proof
The extract info tells which part of the ecosystem that we are interested in knowing about breaking changes. For each library, it is either listed in the extract info or not.
is_listed_in_extract_info(library) -> bool
For each library listed in the extract info, the newest version of the library is known because it is listed in the Cargo.toml given by the url:
know_newest_version(library) -> knowledge
([is_listed_in_extract_info] [:] true) -> [:] known
If we know the newest version, we can detect whether a breaking change occurs:
might_cause_breaking_change(library) -> knowledge
([know_newest_version] [:] X) -> [:] X
Since we know the newest version of libraries listed in the extract info, we know whether they might cause breaking changes:
might_cause_breaking_change([is_listed_in_extract_info] [:] true) -> [:] known
The text was updated successfully, but these errors were encountered:
Eco needs a model of how it knows when a library causes a breaking change, because all automated processes must be correct or have known error cases, which might be hard to figure out from the source. This issue is for tracking the model and proofs based on the planned design.
The definition of "breaking change" used here:
In summary, when a library is listed in the extract info, it is known whether the library will cause a breaking change or not:
If a library is not listed in the extract info, it is not known whether it will cause a breaking change. It might be possible to detect whether it causes a dependency conflict, which is why the definition of "breaking change" does not include dependency conflicts. By design this desirable because:
Proof
The extract info tells which part of the ecosystem that we are interested in knowing about breaking changes. For each library, it is either listed in the extract info or not.
For each library listed in the extract info, the newest version of the library is known because it is listed in the Cargo.toml given by the url:
If we know the newest version, we can detect whether a breaking change occurs:
Since we know the newest version of libraries listed in the extract info, we know whether they might cause breaking changes:
The text was updated successfully, but these errors were encountered: