Request: bump sui-sdk-types to 0.1.0 minimum

[unmaykr-aftermath]

Since any update to a version 0.0.x is considered SemVer-breaking, I think it would be reasonable to have sui-sdk-types bumped to 0.1.0 minimum.

That way, we can have internal fixes and additions to the public API without dependents having to manually update their sui-sdk-types dependency, and in turn having to do a SemVer-breaking update themselves if they export a type from sui-sdk-types

An example:

• crate A depends on sui-sdk-types-v0.0.1 and has a function foo() -> TypeTag
• crate B depends on A and sui-sdk-types-v0.0.1 and uses the return of A::foo to construct sui_sdk_types::types::MakeMoveVector

Then:

1. From<StructTag> for TypeTag gets added to sui-sdk-types; it's bumped to 0.0.2
2. A updates sui-sdk-types and uses the new conversion internally to create the return for foo

The problem will be that A needs a SemVer-breaking version bump, otherwise B will get an type incompatibility error after a cargo update because A is now exporting a new TypeTag type (0.0.2) while B would still be using MakeMoveVector from 0.0.1

[bmwill]

Yes the versioning scheme that is being used right now (0.0.x) is intentional mostly to communicate that this project is still underdevelopment and to give myself, and other contributors, the freedom to not need to worry about ensuring all changes are SemVer compatible yet.

Eventually, yes, I want to move to a 0.X.Y scheme but in order to do that theres a few things i'd like to do:

• Do another pass through the public interface and ensure we're happy with things how they are
• Spend some time documenting the public interface
• introduce some CI checks and/or tooling to assist maintainers and contributors to know when SemVer breaking changes have been made.

None of the above is particularly challenging, its mostly just about finding the time to get these things in order.

If moving towards 0.X.Y versioning scheme is a blocker for your adoption of this library (and for you to continue providing much appreciated feedback) then I can try to do some reprioritization and see about burning down those tasks I listed sooner than I was planning.

[unmaykr-aftermath]

• introduce some CI checks and/or tooling to assist maintainers and contributors to know when SemVer breaking changes have been made.

I've been eyeing cargo-semver-checks and its GH action for a while (for my personal projects). Maybe you'll find it useful

[unmaykr-aftermath]

If moving towards 0.X.Y versioning scheme is a blocker for your adoption of this library (and for you to continue providing much appreciated feedback) then I can try to do some reprioritization and see about burning down those tasks I listed sooner than I was planning.

I could try to work with it as it is, but the cascading version bump behavior I described would make it somewhat unwieldy for us. For context, we run a private Cargo registry and I take SemVer seriously there. We have similar low-level crates that export types used all over the public interface of other libraries. Although rare (because I try to keep them as simple as possible), if there's a SemVer-breaking update to one of them, then the update process takes a little more time

[bmwill]

I've been eyeing cargo-semver-checks and its GH action for a while (for my personal projects). Maybe you'll find it useful

thanks for the pointer, i'll take a look at this and see how we can fit it into the development/release process.

I could try to work with it as it is, but the cascading version bump behavior I described would make it somewhat unwieldy for us. For context, we run a private Cargo registry and I take SemVer seriously there. We have similar low-level crates that export types used all over the public interface of other libraries. Although rare (because I try to keep them as simple as possible), if there's a SemVer-breaking update to one of them, then the update process takes a little more time

Understood, this is another reason why this project exists, in that the main sui repo doesn't really take SemVer seriously and I know that there are builders who would prefer a better stability guarantee when bringing in a library.

All this to say, we'll work to try and get to a better place as quickly as we can :)