Open clearloop opened 8 months ago
Yea we currently dont sync back the versions. I have asked about this a few times as well, since it makes things easier. Now with externals asking maybe there is a point cc @Morganamilo
It is mostly confusing, especially since there is no overview of what has changed (mainly speaking about breaking changes) and (almost) every update seems to be a major version update. Even though I don't think much has changed in basic crates like sp_core_hashing.
Personally I don't think doing a major version bump on a primtive dependency just for having the same starting number is worth making semantic versioning basically useless, but that's a different topic.
Personally I don't think doing a major version bump on a primtive dependency just for having the same starting number is worth making semantic versioning basically useless, but that's a different topic.
Yes absolutely. We are working on it here #2490. It is just our "best effort" until we have that.
Yeah the current situation is not exactly ideal. The original version split stems from Polkadot v1.0.0 releasing and us wanting v1.0.0 as the version in the binary releases. Then when v1.1.0 released, wanting v1.1.0 as the version for that binary release and so on.
This is obviously fundamentally incompatible with crates.io's semver policy as these release do have breaking changes on the library side. Also there were existing crate version published with versions much higher than v1.x.
I'll check with the devs and see If there's support for using the crates.io versions also in the git repo. This may be better for consistency but some people may not like the versions no longer following the release versions.
Personally I don't think doing a major version bump on a primtive dependency just for having the same starting number is worth making semantic versioning basically useless, but that's a different topic.
We're hoping to fix this within the next couple of releases. Bumping the major ver every time is done purely because it is guaranteed to be semver safe and there's currently no procedure+tooling to handle semver across the 100s of crates.
My focus before this has been diffing and not publishing crates that have not changed (and more smartly, have not changed semantically). This doesn't solve the major bump issue but should help as if a crate doesn't change we get no bump at all.
I'm also working on tooling to manage figuring out what version to add as a user so the vast array of versions don't confuse.
Can I ask if this issue is purely an observation or has caused issues on your end? As currently I see this disparity as just a bit ugly and perhaps a cause for confusion. I'd be very interested to know if this has lead to actual Issues for people.
For me only confusion (because I thought the upload to crates.io was not from this repo).
The biggest issues I can see, are:
polkadot-sdk releases should be decoupled with polkadot releases.
Current approach is not "just a bit ugly". It is completely unbearable. Try to submit a PR to upgrade ORML to use 1.4.0 and you will understand.
I will say just forgot about semvar until polkadot-sdk is refactored in such way that it is actually feasible to have semvar, which I don't think it is ever going to happen.
I will say just forgot about semvar until polkadot-sdk is refactored in such way that it is actually feasible to have semvar, which I don't think it is ever going to happen.
Why do you think that per-crate SemVer would not work @xlc ?
Currently the plan is to version each crate according to SemVer and bump the ones that re-export stuff as well. This should allow proper usage of cargo update
. Its not enough you think?
PS: we will encounter the same issues in the runtimes repo https://github.com/polkadot-fellows/runtimes/pull/137, so it should help for finding a good solution.
Are there any big Rust projects that are also mono repo? I did a quick search but didn't find anything similar. Maybe this is a solved problem and we should try to take similar approach as other existing projects?
- There is a risk of using pallets from different releases and there is basically no upside of doing that.
Yea, that is an issue. I will try to do some research if this is a solved problem. Otherwise we could publish a "bundle" polkadot-sdk
crate that locks in dependency exact and the set all other versions to version = "*"
.
Its quite unusual to do that i think, but then we would not build stuff twice and can update all at once with cargo upgrade -p polkadot-sdk
.
Or we make a tool that only pulls the versions from the bundle crate and scans the Cargo.lock
to deny duplicates.
- It is too easy to introduce a breaking change. Any modification to storages and trait config will be a breaking change. It is rarely the case that we can introduce a new feature without breaking change.
Yes, but we want to have an LTS duration of 3 months for now and all breaking changes in the meantime will not hit that LTS branch. They only go on master. I think we have to try at least. There is some tooling to help with spotting breaking changes.
As a parachain developer, I would be interested in how to map a pallet's semver version from crates.io to the corresponding polkadot-sdk
release. I don't hope the best approach is to evaluate this by publishing dates.
"Easiest" way I know of doing it is to look at the crate's Cargo.toml
on the polkadot-sdk
release branches to match versions - but I can first-hand confirm it's a bad UX.
In the future, we could automate adding a description like "released as part of https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-vX.Y.Z" or similar during crate publishing - that should be fairly easy to do while providing considerable pain relief.
For my currently solution, I'm picking the version of frame-support
as an anchor, then match the other packages from the dependencies of frame-support
on publishing them https://crates.io/crates/frame-support/24.0.0/dependencies
It takes pretty much time to test them, and it is really a bad experience doing things like this —— substrate developers are spending uncountable time on handling the bored dependencies of substrate but not building their ideas even though substrate is originally designed for build chains easily, build a substrate chain with 15 mins, and fix it for 15 hours
I still wonder if it would make sense to make a polkadot-sdk
crate that pins all dependencies.
It would not contain any code, only a Cargo.toml
with the all crates as dependencies.
@Morganamilo can you help here if there is a better approach?
We should just stop doing the semvar thing until the codebase is able to cope with it. What are the benefits of having semvar in polkadot-sdk?
What are the benefits of having semvar in polkadot-sdk?
50% of all downloads of sp-core-hashing are 5 or more mayor versions behind, though granted, that one was released only 5 months ago. At the moment on every single release (approx. once per month) everyone using these crates has to go into their Cargo.toml and update the version, then try if anything broke, hoping that everything that broke leads to a compile time error (and ideally read the changelog which as far as I know doesn't exist).
If those crates would use semantic versioning you won't have to do that because cargo can automatically choose the newest one, which should lead to a lot less downloads of really old versions.
Granted, I don't know how many directly depend on those crates (instead of using a bundle as suggested by ggwpez), but I think this graph clearly shows that a lot of projects/crates/whatever do not do this regular mayor version bumping, thus leading to the use of an old version, which could cause a lot of issues down the road.
Yeah obviously semvar is useful for reasons but what I really want to ask is are the pros outweighs the cons? To me the answer is no at this stage. Maybe yes after the new release process is implemented, which I have no idea about how long will it take.
Maybe yes after the new release process is implemented, which I have no idea about how long will it take
Plan is H1 this year (1.7.24).
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Description of bug
sp-api
has version4.0.0-dev
in the git repo https://github.com/paritytech/polkadot-sdk/blob/master/substrate/primitives/api/Cargo.toml#L3however, it has already been bumped to
25.0.0
incrates.io
?ref #2808
Steps to reproduce
No response