Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Release Process #2490
Release Process #2490
Changes from 6 commits
11aa7ac
5eea0df
d8b7524
d622a7c
1e5b3b0
becbb79
316579d
11b77b0
6cdfd59
35d87bf
5189616
a769906
6d61040
d9bf9ef
71d9062
4d65917
1cc2780
423d0ab
9d7bdfd
2bdd380
51322b3
2cd25d9
554b247
d11e585
26d5a8a
7de5e5e
ad657d9
7158244
bfad729
1e10077
f8dea0b
3341c6b
3702afb
dce630d
c3014c4
702118b
ae7e73c
7a4b801
6169ee8
d03a2d3
80b81b1
9328f76
e7032c5
818c013
f36af66
d01c07a
ef1f428
d11235f
09e539a
fc28e27
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
This should be really not done. IMO we should bump the crate versions as we merge stuff to
unstable
.I had written here some things: #2366
I mean I know that is not a perfect thing, but probably the best we can do. IMO this should not be done by a single person or after the fact as this is otherwise too hard to follow.
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.
But if we bump the version of each crate (and all its transitive dependants) in each MR, then we will have huge merge conflicts.
I think if we instead note the version bump in the
prdoc
then it can happen automatically at release process.It would also require is to backport the version bumps from crates-io, leading to even more conflicts.
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.
Hmm? Why would we need to backport version bumps? I mean the version isn't bumping automatically.
If you change something deep inside the tree, I don't want to copy past 300 crate names and their bumps to a prdoc file...
We should not bump in every pr. Bumps should only be done as they are required between releases.
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.
Yea I see. I thought about using
prdoc
to not the semver bump of each crate that i changed, and a script can then take the maximum of all bumps and apply them.It could suffice to note the changed crates - all dependant ones could bump automatically.
Okay yea i read it in the other MR from you. So:
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.
Bumping the dependent crates is not that easy. I mean you only need to bump the dependent crates if you re-export anything as public api.
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.
But when we change something in
sp-io
for example, without modifying the public API but some implementation detail, then we should bump all dependants, or?I am not sure if its easy to manually select which crates to bump, since there is the chance of missing some. If we always bump all dependants then maybe we bump too many, but at least we never miss any.
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.
Assuming we are talking about the
stable
branch here, I disagree for two reasonsIt will be much easier for the developer who made each PR to confidently know which crates changed and how, and for them to make targeted bumps in their PR.
Otherwise, release team will need to do a massive effort identifying and bumping crates based on changes of many PRs from a long time ago they don't understand. This I feel is doomed to fail and is unfair to the release team.
Also, the developer will be expected to write a PRDoc right? If they have the knowledge to write a PRDoc, they may as well bump appropriate crates while they're at it. Otherwise it's just leaving unnecessary extra work for later.
We should strive for automated releases when code is merged to
master
, no more manual release business. This requires the developer to bump their crates when they merge to tomaster
.Yes, I think we should. There are tools to automate these common workspace release tasks: https://github.com/Byron/cargo-smart-release https://github.com/crate-ci/cargo-release https://github.com/pksunkara/cargo-workspaces
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.
I changed it now to make the developer update the crates versions in their Merge Requests (where necessary).
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.
FYI working on a tool for this https://github.com/liamaharon/cargo-workspace-version-tools
Currently able to sync (catch up) our Cargo.toml versions with crates.io. Next will add functionality to bump a crate and automatically have dependent crates also bumped.