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

Crates were not bumped in PR #1230 #1275

Closed
GitGab19 opened this issue Dec 7, 2024 · 5 comments · Fixed by #1300
Closed

Crates were not bumped in PR #1230 #1275

GitGab19 opened this issue Dec 7, 2024 · 5 comments · Fixed by #1300
Assignees
Milestone

Comments

@GitGab19
Copy link
Collaborator

GitGab19 commented Dec 7, 2024

PR #1230 changed some crates under protocols to be no_std, without bumping their versions.

Now this is creating some errors in the CI execution of semver-checks, such as here: https://github.com/stratum-mining/stratum/actions/runs/12211524808/job/34069218188?pr=1242.

We need to bump versions of crates which were modified there to fix this and unblock all the docs PRs.

Specifically, we need to bump the major version number of:

  • serde_sv2
  • const_sv2
  • framing_sv2
@GitGab19 GitGab19 self-assigned this Dec 7, 2024
@jbesraa
Copy link
Contributor

jbesraa commented Dec 8, 2024

I would remove the semver check from ci and move it into a script that we run manually before creating a new release

@plebhash
Copy link
Collaborator

plebhash commented Dec 8, 2024

I would remove the semver check from ci and move it into a script that we run manually before creating a new release

@GitGab19 feels we should catch semver deviations as soon as possible, and I tend to agree

but it's also important to highlight that something is not working as expected

we merged #1230 without CI blocks, and now we are getting this behavior

ideally #1230 should have been blocked by this semver check

@Fi3
Copy link
Collaborator

Fi3 commented Dec 9, 2024 via email

@plebhash
Copy link
Collaborator

plebhash commented Dec 9, 2024

we merged #1230 without CI blocks, and now we are getting this behavior

ideally #1230 should have been blocked by this semver check

this happened because our CI was using whatever was the latest release of cargo semver-checks, and obi1kenobi/cargo-semver-checks#1015 introduced a change of behavior into v0.37.0, which was released only 4 days ago (which explains the recent change of CI behavior)

the solution was #1276 where we are locking CI to always use cargo semver-checks on release v0.33.0 in order to always have the same behavior of the tool

@plebhash
Copy link
Collaborator

todo: follow up to #1276 that locks cargo semver-checks on 0.37.0

this CI will have to run on rust stable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants