Open xlc opened 1 month ago
In theory yes, it's definitely possible. I can see there is a Cargo.dev.toml
in the root of the repo containing the versions. If this file is up to date (meaning that it contains the same version published for each crate as its crates.io release), then the only thing needed is to add the workflow of parsing this file, create the mapping and merge this mapping with the Polkadot SDK mapping.
I see there are branches in the repository with Polkadot SDK versions like polkadot-v1.9.0
. Are this branches always up to date with the packages published in crates.io? All this branches contain an up to date Cargo.dev.toml
file? Is the publishing process automatized? Are all the crates mentioned in Cargo.dev.toml
published in crates.io for all the polkadot branches?
The Cargo.dev.toml is up to date. i.e. It is the file used for the publishing process. I am using cargo release to do the publishing One thing to keep in mind is that we don't update ORML for every polkadot-sdk release. e.g. there is no polkadot-v1.8.0 one and it can takes a few weeks delay before we update ORML to latest polkadot-sdk release.
All the crates in ORML have a same version number and all of them get released.
In this case, I think is totally possible to integrate it. If ORML doesn't exists for an specific version, when trying to upgrade the versions of a project, the tool will just skip the ORML crates (potentially could be possible to add a warning in case a ORML crate is detected). Therefore, for now we could add a --orml flag to the CLI that if used, will fetch the versions from ORML's Cargo.dev.toml
, parse them into a versions mapping and merge this mapping with the Polkadot SDK mapping before the mapping is applied to the project being upgraded.
Is it possible to make psvm also supports other pallets like ORML? In that way it can identify the right version of ORML to use. Happy to do whatever needed on ORML side to make this possible.