- cargo deny: add MPL-2.0 and BSD-3-Clause to allow list (colored via
simple_logger/mockito; encoding_rs via reqwest)
- conventional commits: use explicit SHA of last pre-conventional commit
instead of from_latest_tag (no tags exist yet in the repo)
- MSRV: raise rust-version 1.80 -> 1.88 to match the actual minimum
required by the dependency tree (simple_logger -> time 0.3 -> 1.88)
- MSRV CI: update toolchain pin to 1.88 to match
- macOS test: remove Swatinem/rust-cache from test matrix job to avoid
stale cache corrupting the cargo binary path on arm64 runners
- Replace serde_yml with serde_norway (RUSTSEC-2025-0068: serde_yml is
unsound and archived; serde_norway is the recommended maintained fork)
- Remove unused toml dependency (was resolving to v1.1.2 which requires
edition2024/Rust 1.85, breaking the MSRV 1.80 check)
- Run cargo fmt to fix formatting diffs caught by lint job
- Fix cog commit check to use from_latest_tag so pre-conventional-commits
history does not cause the check to fail
- Remove semver job: dredge is a binary-only crate with no lib target,
cargo-semver-checks cannot check it
This changes the effective license from a simple Apache-2.0 license to a
dual license consisting of both Apache-2.0 and the MIT license to be more
compatible for use in GPL Code.
The MIT license requires reproducing countless copies of the same copyright
header with diffferent names in the copyright field, for every MIT library
in use. The Apache license does not have this drawback. However, this is not
the primary motivation for creating these issues. The Apache license also has
protections from patent trolls and explicit contribuition licensing clause.
However the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache.
If the Docker Registry API allows for images to be deleted, issuing the
command `delete <image> <tag>` will result in the tag being removed from
the server.
A limitation of this change is that it will cause any unreferenced tags
to become orphaned, requiring the garbage collector within the docker
registry server to clean these up. This is because there is no way to
efficiently determine if each of the layers are reused by other tags or
images on the server.
Implement delete logic
Fix broken unit tests
Anthony Oteri
dependabot[bot]
Anthony Oteri