There are initiatives going to verify the current published version of a crates on crates.io against their tagged version in a vcs. Out of curiosity I verified all 87 versions of chrono.
Rust versions
cargo package rewrites cargo.toml and adds .cargo_vcs_info.json. There have been some changes to the format and formatting over the years. So to replicate the package of older versions of chrono we need to use older versions of Cargo. The following versions worked for me:
Chrono 0.1.0 to 0.1.6: rust 1.0
Chrono 0.1.7 to 0.4.0: rust 1.15
Chrono 0.4.1 to 0.4.6: rust 1.24
Chrono 0.4.7 to 0.4.19: rust 1.35
Chrono 0.4.20 to current: current rust releases
Changes
Chrono 0.1.0 to 0.1.5
These versions had a git dependency on time and num. For the crates.io release these dependencies are changed to a version number, but these changes were never checked in.
Given how much everything was in flux just before rust 1.0 this seems reasonable.
Chrono 0.3.1
The bincode dev-dependency was specified as a git repository because there was no release that supported Serde 1.0 at the time of release.
The crates.io release still pointed to the incompatible 0.7 release.
Chrono 0.4.8
Tag is placed at the wrong commit: it should be 630cade52a1c1e3d68f0a86936806eb305e62632 instead of a70c5cdc79649a4f7627a988ba6045872a4eb5c1. It is the merge commit after one more change: to ignore a warning for ellipsis_inclusive_range_patterns.
Chrono 0.4.14
The crates.io release is made from a branch that did not make it into main. The only difference is a change to GitHub Actions for testing release branches. Our CI configuration shouldn't be part of the release package anyway.
GitHub still had the commit, even though it doesn't exist in a clone of the repo. I recovered it as a 0.4.14 branch.
Chrono 0.4.20-beta.1
A tag for this release was missing, I added it.
Next work
Do we want to update the tags for 0.4.8 and 0.4.14 to point to the proper commits?
And do we want to mention the differences in the GitHub release notes?
There are initiatives going to verify the current published version of a crates on crates.io against their tagged version in a vcs. Out of curiosity I verified all 87 versions of chrono.
Rust versions
cargo package
rewritescargo.toml
and adds.cargo_vcs_info.json
. There have been some changes to the format and formatting over the years. So to replicate the package of older versions of chrono we need to use older versions of Cargo. The following versions worked for me:Changes
Chrono 0.1.0 to 0.1.5
These versions had a git dependency on
time
andnum
. For the crates.io release these dependencies are changed to a version number, but these changes were never checked in.Given how much everything was in flux just before rust 1.0 this seems reasonable.
Chrono 0.3.1
The
bincode
dev-dependency was specified as a git repository because there was no release that supported Serde 1.0 at the time of release.The crates.io release still pointed to the incompatible 0.7 release.
Chrono 0.4.8
Tag is placed at the wrong commit: it should be 630cade52a1c1e3d68f0a86936806eb305e62632 instead of a70c5cdc79649a4f7627a988ba6045872a4eb5c1. It is the merge commit after one more change: to ignore a warning for
ellipsis_inclusive_range_patterns
.Chrono 0.4.14
The crates.io release is made from a branch that did not make it into
main
. The only difference is a change to GitHub Actions for testing release branches. Our CI configuration shouldn't be part of the release package anyway.GitHub still had the commit, even though it doesn't exist in a clone of the repo. I recovered it as a 0.4.14 branch.
Chrono 0.4.20-beta.1
A tag for this release was missing, I added it.
Next work
Do we want to update the tags for 0.4.8 and 0.4.14 to point to the proper commits? And do we want to mention the differences in the GitHub release notes?