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

v1.2.5 Release #316

Closed
7 tasks done
joepetrowski opened this issue May 19, 2024 · 12 comments
Closed
7 tasks done

v1.2.5 Release #316

joepetrowski opened this issue May 19, 2024 · 12 comments

Comments

@joepetrowski
Copy link
Contributor

joepetrowski commented May 19, 2024

@muharem
Copy link
Contributor

muharem commented May 28, 2024

It would be nice to include this

@eskimor
Copy link
Contributor

eskimor commented May 29, 2024

@muharem
Copy link
Contributor

muharem commented May 30, 2024

@joepetrowski it's not clear with the plan with CheckMetadataHash extension?

@joepetrowski
Copy link
Contributor Author

@joepetrowski it's not clear with the plan with CheckMetadataHash extension?

We need to bump to the patch releases of these crates: paritytech/polkadot-sdk#4635

@seadanda
Copy link
Contributor

The changes in question depend on a breaking change to the broker pallet in v0.13.0.
To get this into the next release we have to either:

  1. update a lot (most?) of the dependencies in the repo
  2. backport this breaking change to the broker as a 'fix' to broker 0.7 (based on the 1.7 sdk release)
  3. use a git version for the broker pointing to an unreleased version of 2

1 would delay the release by a fair bit, 2 is a pretty bad semver violation and then I know that there is a lot of resistance to 3 being in the codebase.

What are people's opinions on which way is least bad?

@bkchr
Copy link
Contributor

bkchr commented May 31, 2024

3. use a git version for the broker pointing to an unreleased version of 2

We need to use a patch in the workspace Cargo.toml that uses git.

@acatangiu
Copy link
Contributor

  1. backport this breaking change to the broker as a 'fix' to broker 0.7 (based on the 1.7 sdk release)

2 is a pretty bad semver violation

Are there any other users of the broker pallet? Afaik this is pretty new and its usecase is also very specific. It might actually not break anyone.

@seadanda
Copy link
Contributor

There were some unrelated changes in the PR which changed the broker which required a migration, and there is already a broker migration from another commit which has not yet run on coretime-kusama. To avoid messing up storage versions, I've isolated the relevant changes for the price adapter and backported them in this PR.

I'd like a second pair of eyes on it before using it as it wasn't just a straightforward backport. Can re-target the PR onto another branch as needed, and whether we go for option 2 or 3 this should be sufficient.

@muharem
Copy link
Contributor

muharem commented Jun 3, 2024

@joepetrowski
Copy link
Contributor Author

I think this can probably go into 1.2.6 with the other People stuff. We need to prioritize the Coretime changes for 1.2.5 due to the Kusama timeline.

@eskimor
Copy link
Contributor

eskimor commented Jun 5, 2024

  • Run benchmarks for broker pallet.

@joepetrowski
Copy link
Contributor Author

joepetrowski commented Jun 6, 2024

fellowship-merge-bot bot pushed a commit that referenced this issue Jun 6, 2024
Trigger #316

`transaction_version` is bumped due to changed `SignedExtra`.

Do not merge until the Broker patch is included (cc @eskimor @seadanda).

- [x] Does not require a CHANGELOG entry

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants