Advance gix-features version, as it republishes bytesize version 2
#1957
Conversation
EliahKagan
force-pushed
the
run-ci/versioning
branch
from
1459a0c to
7289db4
Compare
`gix-features` republishes `bytesize`, which has been bumped from major version 1 to major version 2. Because the interface of `bytesize` is effectively part of that of `gix-features` due to the explicit republication of the `bytesize` module in full (with no documented extra limitations related to interface stability), this is effectively a breaking change in `gix-features` as well, though many callers may not be substantially affected. Major changes that may affect some callers that use `bytesize` through `gix-features` include the removal of the top-level `bytesize::to_string()` function, the change in default behavior from displaying decimal SI units to displaying binary IEC units (though all or most gitoxide-related creates, in adapting to the changes, have thus far opted to continue using decimal SI units), and the small but UI-facing change that decimal SI kilobytes (units of 1000 bytes) are given with the symbol "kB" rather than the more ambiguous (and arguably less accurate) symbol "KB". In addition to republishing `bytesize`, `gix-features` also republishes `prodash`. Futhermore, some uses of `bytesize` are transitively through `prodash`, which itself has recently received an update to use `bytesize` major version 2. (Since `prodash` does not republish `bytesize`, that is not considered to be a breaking change in `prodash` itself.) To get the benefits of the newer version of `bytesize` while avoiding new inconsistencies, and also to avoid depending on multiple versions of `bytesize`, the `prodash` dependency version has also been upgraded. For more information, see: - GitoxideLabs#1952 - https://github.com/bytesize-rs/bytesize/releases/tag/bytesize-v2.0.0 - GitoxideLabs#1949 - GitoxideLabs/prodash#33 - GitoxideLabs#1953
This does not increment their package versions, which can be done when they are actually being released. It only bumps the versions of `gix-features` they specify as dependencies, to allow them to build again after the "out of band" version bump done in the preceding commit. For context, see the preceding commit as well as: GitoxideLabs#1952
EliahKagan
force-pushed
the
run-ci/versioning
branch
from
7289db4 to
6315536
Compare
There was a problem hiding this comment.
Thanks a lot, this will work!
- The commit that increases the version number in
gix-featuresis itself a conventional commit. The idea is to get this into the changelog too. I don't know if that makes sense, though. Will that result incargo-smart-releasebumping the version again so as to skip this version? (I had originally thought to usefeat:instead offeat!:, but iffeat!:causes a problem, then I thinkfeat:causes an only slightly less severe variant of that problem:cargo-smart-releasewould still change the version number.)
Indeed, it would want to have a breaking change compared to the last published version, increment the current (already incremented one), but then notice that the current version is already enough to indicate a breaking change, and do nothing effectively.
- A number of references to
gix-featuresgive its path but also a version number. Since the version number at that path is changed, they also have to be updated. Thus the second commit here changes the version of thegix-featuresdependency in various crates that depend on it. But the other parts of those crates'Cargo.tomlfiles are the same. For example, I have not advanced their version numbers--this is with the idea thatcargo-smart-releasewill do so.
I don't know what these other parts would be, but as long as Cargo can build the project, the version update was done correctly.
For safety I checked that there indeed is no unchanged gix-features reference in any Cargo manifest.
Ah, sounds good. (I take this to mean that the published version will not, in effect, be any higher, unless there is a reason for it to be.)
Probably just those dependent crates' versions. And I'm not really sure what I was worried about there--crates get new and changed dependencies all the time prior to their own version numbers being bumped immediately before their next release.
Thanks! |
Yes, their version number will be bumped automatically. CSR has many flaws, but this one thing is does pretty well 😅. |
From #1952 (reply in thread), you had explained:
Per #1952 (reply in thread), I don't know if that needs to be done at the time of publication and not before. If it should not be done now, then this PR can simply be closed. I figured that, rather than try to exhaustively describe this idea in the discussion in #1952, I would open a PR for it and let the PR be reviewed.
This attempts to increase the
gix-featuresversion number now so that, regardless of the circumstances, any latergix-featuresrelease that republishesbytesizeversion 2 will carry a version number consistent with a breaking change.Even if this is the right thing to do, I am not sure if I have done it in the right way. In case this would cause other problems, I will refrain from merging this without a review.
gix-featuresis itself a conventional commit. The idea is to get this into the changelog too. I don't know if that makes sense, though. Will that result incargo-smart-releasebumping the version again so as to skip this version? (I had originally thought to usefeat:instead offeat!:, but iffeat!:causes a problem, then I thinkfeat:causes an only slightly less severe variant of that problem:cargo-smart-releasewould still change the version number.)gix-featuresgive its path but also a version number. Since the version number at that path is changed, they also have to be updated. Thus the second commit here changes the version of thegix-featuresdependency in various crates that depend on it. But the other parts of those crates'Cargo.tomlfiles are the same. For example, I have not advanced their version numbers--this is with the idea thatcargo-smart-releasewill do so.Information relevant to people who may be reading the commit history or changelog are in the commit messages. In particular, the first commit message contains a description of the situation and the effect of the changes that have already been made but that motivate the change in version number.