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

Pin intra-libcnb* crate dependencies to exact versions #644

Merged
merged 1 commit into from
Aug 18, 2023

Conversation

edmorley
Copy link
Member

@edmorley edmorley commented Aug 18, 2023

Cargo treats dependency version specifiers of form X.Y.Z the same as ^X.Y.Z:
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements

As such, previously if an end user of libcnb tried pinning to say libcnb 0.14.0, then its previous dependency on libcnb-data 0.14.0 would mean any patch releases to libcnb-data (such as 0.14.1) would be automatically picked up.

This could be potentially confusing, especially since we only have one unified version number and changelog for libcnb now.

For example:

  1. A buildpack maintainer has an issue with a libcnb upgrade, so pins libcnb to =0.14.0 in their CNB's Cargo.toml.
  2. However, Cargo when refreshing their CNB's Cargo.lock now records the libcnb-data version as 0.14.1, since it's in-range.
  3. Now their CNB is using a combination of 0.14.0 and 0.14.1, which confuses the buildpack maintainer, since as far as they are concerned they are using libcnb 0.14.0, and so they don't expect the changes documented under the 0.14.1 section of libcnb's unified changelog to be taking effect.

GUS-W-13973440.

Cargo treats dependency version specifiers of form `X.Y.Z` the
same as `^.X.Y.Z`:
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements

As such, previously if an end user of libcnb tried pinning to say `libcnb`
0.14.0, then its previous dependency on `libcnb-data` `0.14.0` would
mean any patch releases to `libcnb-data` (such as `0.14.1`) would be
automatically picked up.

This could be potentially confusing, especially since we only have one
unified version number and changelog for libcnb now.

For example:
1. A buildpack maintainer has an issue with a libcnb upgrade, so pins to
   `libcnb@=0.14.0` in their CNB's `Cargo.toml`.
2. However, Cargo when refreshing their CNB's `Cargo.lock` now records
   the `libcnb-data` version as `0.14.1`, since it's in-range.
3. Now their CNB is using a combination of 0.14.0 and 0.14.1, which confuses
   the buildpack maintainer, since as far as they are concerned they are using
   libcnb 0.14.0, and so they don't expect the changes documented under the
   `0.14.1` section of libcnb's unified changelog to be taking effect.
@edmorley edmorley merged commit 2b935db into main Aug 18, 2023
12 checks passed
@edmorley edmorley deleted the edmorley/pin-intra-crate-versions branch August 18, 2023 11:27
colincasey added a commit that referenced this pull request Aug 18, 2023
* main:
  Bump buildpacks/github-actions from 5.3.1 to 5.4.0 (#647)
  Prepare release v0.14.0 (#646)
  Pin intra-libcnb* crate dependencies to exact versions (#644)
  Rename libcnb-cargo integration test file (#645)
  Add version links in the changelog (#643)
  Update Quick Start Guide (#640)
  Run `cargo upgrade` as part of preparing libcnb releases (#641)
  Move packaged buildpack directory out of `target/` (#583)
  Refactor libcnb-cargo integration tests (#637)
  libcnb-test: Improve error messages for `address_for_port` (#636)
  libcnb-test: Implement `fmt::Display` for `LogOutput` (#635)

# Conflicts:
#	CHANGELOG.md
#	libcnb-cargo/src/package/command.rs
colincasey added a commit that referenced this pull request Aug 18, 2023
…cator

* main:
  Bump buildpacks/github-actions from 5.3.1 to 5.4.0 (#647)
  Prepare release v0.14.0 (#646)
  Pin intra-libcnb* crate dependencies to exact versions (#644)
  Rename libcnb-cargo integration test file (#645)
  Add version links in the changelog (#643)
  Update Quick Start Guide (#640)
  Run `cargo upgrade` as part of preparing libcnb releases (#641)
  Move packaged buildpack directory out of `target/` (#583)
  Refactor libcnb-cargo integration tests (#637)
  libcnb-test: Improve error messages for `address_for_port` (#636)
  libcnb-test: Implement `fmt::Display` for `LogOutput` (#635)

# Conflicts:
#	CHANGELOG.md
#	libcnb-cargo/src/package/command.rs
#	libcnb-cargo/src/package/error.rs
#	libcnb-cargo/tests/test.rs
#	libcnb-package/src/lib.rs
colincasey added a commit that referenced this pull request Aug 18, 2023
… libcnb-package/assembling_buildpack_directories

* libcnb-package/buildpack_output_directory_locator:
  Bump buildpacks/github-actions from 5.3.1 to 5.4.0 (#647)
  Prepare release v0.14.0 (#646)
  Pin intra-libcnb* crate dependencies to exact versions (#644)
  Rename libcnb-cargo integration test file (#645)
  Add version links in the changelog (#643)
  Update Quick Start Guide (#640)
  Run `cargo upgrade` as part of preparing libcnb releases (#641)
  Move packaged buildpack directory out of `target/` (#583)
  Refactor libcnb-cargo integration tests (#637)
  libcnb-test: Improve error messages for `address_for_port` (#636)
  libcnb-test: Implement `fmt::Display` for `LogOutput` (#635)

# Conflicts:
#	CHANGELOG.md
#	libcnb-cargo/src/package/command.rs
#	libcnb-package/src/output.rs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants