Versioning Scheme Discussion

[terrarier2111]

Hello, I wanted to get into wgpu today and noticed that i couldn't use wgpu 0.13.2 in my cargo.toml but only wgpu 0.13.1 which left me confused as the changelog clearly has a release date for 0.13.2, is this intentional?
Furthermore i wanted to use winit 0.27 as there is an annoying bug on wayland which was fixed in winit 0.27 but i noticed that i couldn't use it, but I assume this won't be a problem anymore after #2918 got merged. Are there any plans on when to expect a wgpu release with winit 0.27 support?
Thanks for your amazing work wgpu-team :)

[CatCode79]

The external API (wgpu crate) is still at version 0.13.1 while the inner API (wgpu-core, wgpu-hal, and so on) are at version 0.13.2.

I think that having released the latest wgpu tagged with 0.13.2 can actually generate some confusion.

You can use on your Cargo.toml file this line:
wgpu = "0.13"
omitting the minor version and cargo will handle everything for you.

(+1: I too would like, if possible, that wgpu has winit and raw-window-handle updated)

[cwfitzgerald]

Is there a better way that we could express this? I want to allow the tags to exist to easily access version specific change logs and to grab the exact commit that corresponds with a version, but I also don't want unnecessary confusion.

[CatCode79]

I have various solutions in my head, one uglier than the other..

This is my best one:

• Rename the wgpu crate to wgpu-api or similar.
• Create a new wgpu crate that imports, in the only lib.rs file it contains, all the namespace of wgpu-api as is.
• The new crate wgpu will contain the information of the version, aligned with the github tag, which equals the sum of all the minors of the other wgpu crates.

Taking as an example the current state of the crates the versions will look like this:
wgpu-api v0.13.1 (ex wgpu crate)
wgpu-core v0.13.2
wgpu-hal v0.13.2
wgpu-types v0.13.2
deno-webgpu v0.64.0

The new wgpu crate will have as a version the sum of the minor versions of the other crates:
wgpu v0.13.7

This allows you to separate the semantics of the crate wgpu-api from the version-tag of the project.
I think it can also give a more concrete view of the evolution of wgpu project with a cumulative counter of this type.
It seems to me that the changes are not breaking API side, they are in the semantic of the versions, so if my idea is ever accepted it is probably better to apply it from version 0.14 onwards.

--- Post Scriptum Edited Part: ---

Thinking about it by accumulating minor versions is not a good idea, since usually more crates are modified and in this case creating a new release would give us holes between one minor version and another.
So it's probably better to keep a minor version numbering, for the new crate wgpu I thought, aligned with the number of releases.

[cwfitzgerald]

I'm not particularly hot on adding more crates for the sole purpose of making a better version number. This has a non-zero cost on compile time, and involves some political blahblah on various upstream projects.

One option is that I can just always release the wgpu crate every time. This doesn't really accomplish anything at the end of the day, but would make it seem like things are updated. Otoh, it would make it seem things are updated when the core components are still not-updated.

In the mean time, I added some more information to the github releases regarding which crates got released in that version.

[CatCode79]

Yes, it is definitely the easiest and fastest thing to do; although there is potential confusion on the part of the user in seeing a new version in an unmodified crate, this confusion is less than that generated by the current situation.

Also qualitatively the confusion is different, currently, as we have seen, it can generate doubts about how to configure the version while in the case of your solution I think it can generate more perplexity than anything else.

[cwfitzgerald]

This should be covered by info in github releases