Bump toolchain and rust_version to 1.89.0

[kskalski]

We are using old toolchain, no harm in building with newest stable version, we set rust-version separately.

[kskalski]

Would like to migrate both toolchain and rust-version to at least 1.85, so we can switch to edition 2024 and enable some more convenient language syntax / trim down the drop semantics.

[febo]

The rationale for using an older toolchain is that we keep compatibility with platform-tools' Rust version, which is what on-chain programs are compiled with.

If we bump the requirement then we can't use the latest version of wincode in programs.

[kskalski]

I see, this PR doesn't strictly break it, but I guess we want some test coverage for the older toolchain.

[steviez]

The rationale for using an older toolchain is that we keep compatibility with platform-tools' Rust version, which is what on-chain programs are compiled with.

If we bump the requirement then we can't use the latest version of wincode in programs.

Does the wincode version have to match the platform tools Rust version exactly ? Platform tools is not the only consumer of wincode so having wincode Rust version coupled to platform tools Rust version is not ideal.

Some other questions about platform tools:

• How often does Rust version adjust there ?
• Does platform tools need any other wincode features asap ? Bumping MSRV requires a major if I'm not mistaken, but release branches could potentially allow us to pick up new features (via cherry-pick) on an older branch

[steviez]

Would like to migrate both toolchain and rust-version to at least 1.85, so we can switch to edition 2024 and enable some more convenient language syntax / trim down the drop semantics.

Generally, we probably don't want to bump MSRV (and thus create a new major) every time new stable rust drops. However, edition is once every couple years so probably reasonable to bump it to pick up the new edition and then leave it alone for a while.

Let's see what febo says to some of my above questions tho and we can figure out plan forward from there

[febo]

Does the wincode version have to match the platform tools Rust version exactly ? Platform tools is not the only consumer of wincode so having wincode Rust version coupled to platform tools Rust version is not ideal.

It does not need to be an exact match, but if we want to use wincode in programs we sort of need to be conservative in what version we can use. Currently we are using 1.84.1 since it corresponds to platform-tools 1.51. There are a couple of versions after that one (1.52 and 1.53) but they have a few performance regressions.

Some other questions about platform tools:

• How often does Rust version adjust there ?

They do not follow every release, e.g.,:

• 1.51 comes with Rust 1.84.1
• 1.52 and 1.53 with Rust 1.89.0

• Does platform tools need any other wincode features asap ? Bumping MSRV requires a major if I'm not mistaken, but release branches could potentially allow us to pick up new features (via cherry-pick) on an older branch

platform-tools is independent of wincode. The requirement is that we use platform-tools to compile programs, so any program is limited by the bundled Rust version. If we increase the requirement, then we can't use a particular wincode version in programs.

A new version of platform-tools (1.54) should be out soon. It fixes the regressions and it will have 1.89.0 bundled.

[febo]

@kskalski @steviez New platform-tools was released. It comes with Rust 1.89.0 so a bump up to that version would be fine for programs.

[steviez]

I see the PR is still in draft state - anything else to do here before reviewing ?

[kskalski]

Waiting for CI mostly. But I wonder if we should land it on 0.4 line or wait until we are ready to release (including breaking changes) 0.5.

[steviez]

Waiting for CI mostly. But I wonder if we should land it on 0.4 line or wait until we are ready to release (including breaking changes) 0.5.

Hmm, good point; this does seem like something we'd want to put in a "major" (actually a minor b/c we're in 0.x.y). Not sure if we had other changes in mind for the 0.4 line or if we could bump to 0.5 today

[kskalski]

We are not yet ready for 0.5, there is one problem that Zach wants to solve (in #220) and we are having a discussion which APIs should be added in 0.4 such that we can properly deprecate the ones we want ahead of #213 (to land in 0.5)

[cpubot]

This should be good to merge now