Stability guarantees of `winit-common`?

[madsmtm]

We decided in #4274 that we would have a single shared version for all our winit-* crates.

That does leave winit-common in kind of a weird place, since it's meant to be internal, but a breaking change in that is observable even if nobody outside of our own crates depend on it.

For example, things might break if users run cargo update -pwinit-common, since then they'd only get the new version of winit-common, while e.g. their version of winit-appkit might've relied on something that is no longer there.

I see a few ways of resolving this:

• Use precise versioning when depending on the common crate, effectively opting it out of SemVer (e.g. winit-common = "=0.31.0").
• Consider the common crate public API. The main downside of this is that it currently quite heavily exposes the dependency on objc2 and x11-dl, so that prevents us from updating the major version of either of these in a patch release of Winit.
• Explicitly declare it as internal (but then it should maybe have been called winit-internal?), and consider updating only winit-common an unsupported use-case.
• Use a different versioning scheme.
• Remove it, and "import" the required things from it into the other crates with symlinks.

What do you think?

[kchibisov]

The point is not not break winit-core. The rest doesn't really matter. And library must be able to do pretty much everything with just core. The winit-common must also not be publicly exposed in any crate.

For example, things might break if users run cargo update -pwinit-common, since then they'd only get the new version of winit-common, while e.g. their version of winit-appkit might've relied on something that is no longer there.

This is not how semver works.