Question: BCS-compatibility guarantees

[unmaykr-aftermath]

Hi folks. I've been following closely the development of sui-sdk-types and I'm eager to use it. I've already done tests to confirm it's compatible with our codebase on the compilation level.

The main clarification I'm seeking before migrating some of our codebase is: will sui_sdk_types::types::CheckpointData always be BCS-compatible with the checkpoint data produced by the latest testnet version?

That should cover almost all types that are relevant to applications that act on data post-execution on the Sui network. It would also allow builders like us to develop custom indexing pipelines without depending on the MystenLabs/sui repo at all.

And more generally, it would be good to have the (de)serialization compatibility guarantees stated directly in the repository Overview

[bmwill]

Hi! Thanks for your interest in this new rust sdk. The eventual goal for this project is to be the goto rust sdk for builders to use to integrate with Sui. So to that end, yes, the expectation and goal of this library is to be BCS-compatible with all of the public, core types of Sui (Checkpoint, Object, Transaction, etc). If something isn't compatible we'd treat that as a bug to be fixed.

Given new enum variants are occasionally added to some types there may be times where a new variant may not be supported yet but the goal would be to minimize the time where there is this gap.

And more generally, it would be good to have the (de)serialization compatibility guarantees stated directly in the repository Overview

Thanks for the suggestion, i'll look to get something added here shortly.

[unmaykr-aftermath]

Given new enum variants are occasionally added to some types there may be times where a new variant may not be supported yet but the goal would be to minimize the time where there is this gap.

I expect that to be the case when compared to the main branch of MystenLabs/sui, no problem. It would be good, IMHO, to have it compatible by the time the new variant is being generated by the testnet validators.

So, for example, the new Owner::ConsensusV2 was recently added to the monorepo, but IIUC testnet is not producing these types of objects yet. So it would be fine for sui-sdk-types to not have it yet, IMO, since someone deserializing CheckpointData wouldn't be affected.

I know testnet might not seem like a huge priority, but we test a lot of our infra on it. So having the deserialization compatibility guarantee against testnet is a make-or-break deal for us. Hope this perspective helps clarify things

[bmwill]

It would be good, IMHO, to have it compatible by the time the new variant is being generated by the testnet validators.

I agree, this sounds like a reasonable goal for this project to have.