Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When a library is known to cause a breaking change #16

Closed
bvssvni opened this issue Aug 10, 2015 · 0 comments
Closed

When a library is known to cause a breaking change #16

bvssvni opened this issue Aug 10, 2015 · 0 comments

Comments

@bvssvni
Copy link
Member

bvssvni commented Aug 10, 2015

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:

  1. Some libraries are stable and have stable dependencies. We are not interested in extracting information in this case.
  2. 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.
  3. 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
@bvssvni bvssvni changed the title When a library is known to cause a breaking change or not When a library is known to cause a breaking change Aug 10, 2015
@bvssvni bvssvni removed the draft label Aug 24, 2015
@bvssvni bvssvni closed this as completed Aug 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant