-
Notifications
You must be signed in to change notification settings - Fork 984
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
fix(dcutr): rename error types to bypass cargo-semver-checks
hickup
#3213
Conversation
160a9c6
to
fa8151e
Compare
cargo-semver-checks
hickup
Lol, I was about to say "damn it doesn't work" until I released that the failure this time is actually correct and I did break the API with that change. Oh the irony 😄 |
Unfortunately, it actually doesn't work. I am guessing because of the same issue, Any more ideas @obi1kenobi? Otherwise, I'd suggest that we merge #3214 but without the rename of the inner type but instead deprecate it for the ones scoped under the new |
The false-positive will go away as soon as you merge this PR, and there are no semver violation here as far as I can tell so it should be safe to ignore The semver-checking in CI for this PR is using the 0.8.0 version as a baseline. Because of the renaming re-export, that causes an incorrect view of what types are available under which names, and false-positives happen. But as soon as 0.8.1 gets published, that version will then become the baseline for future runs, and the false-positive will go away. Here's how I know: this false-positive is such that testing a version against itself reports semver violations (which are obviously impossible). Testing v0.8.0 against itself reports false-positive violations, but testing v0.8.1 (this PR) against itself finds none (correctly so). Here's v0.8.0 being tested against itself. This is using the exact same rustdoc JSON file being used as both the baseline and the current version, as you can see in the flags below:
And here's v0.8.1 (this PR) being tested against itself in the same way:
Both of these commands were executed from the root of the repo after a single |
This pull request has merge conflicts. Could you please resolve them @thomaseizinger? 🙏 |
Thanks for the detailed explanation @obi1kenobi ! That is what I thought would happen, great to have it confirmed! @mxinden Can you prioritise this so that our CI is green again? :) |
I think we should get away with not renaming the inner type which would make this PR smaller. I'll do that tomorrow. If you happen to have time for a release before that @mxinden , I'd appreciate it if you could include that :) (Just on mobile atm so can't push code.) |
Not sure I understood this part. For In any case, you should be able to locally test any changes with |
It seems to work :) Both of these commands are executed on the current branch!
|
…2p into fix-semver-check-hickup
Okay, I think I have arrived at the absolute minimal fix for this problem! I think this is what we should merge and release. I'll deal with the deprecations separately in #3214. @mxinden I also removed the bump of the lib in |
@obi1kenobi I've ran the commands you used as well and the latter one now passes without problems! Can you maybe double check that I actually did this correctly? |
Thanks for looking so deep into this @thomaseizinger and @obi1kenobi. We need to release a new breaking version of Any objections simply proceeding with #3225? What would be the benefit of this pull request and the additional patch release of |
We need to get rid of the export rename, otherwise we have the same problem on the next release! If you are already bumping it there, then we don't need to release it but either way, this PR needs to merge :) |
The Right now I think I think this is fine to merge, even though renaming the underlying types might have been just a touch safer. |
I am planning to land #3214 shortly after, meaning the type aliases are only a short-term fix in any case and not planned to be part of the public API for long. It is good to know that they are ignored for now, will keep it in mind! |
This pull request has merge conflicts. Could you please resolve them @thomaseizinger? 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs updates to changelog and version. Otherwise good to go from my end.
Damn, I forgot to update the pull-request description. It is outdated :( |
Description
cargo semver-checks
is still missing features in regards to properly detecting renamed exports. To make our CI pass again, we remove the renamed export, replace it with type-aliases and deprecate them to point users types exported under a module which now follows the conventions set in #2217.Notes
Links to any relevant issues
Open Questions
Change checklist