Sync version with Glutin?

[felixrabe]

I don't know if it's just me, but I find it confusing that the version of winit (0.17.x) and glutin (0.18.x) are off by one. Could they be synced on the next breaking change, so that winit 0.19 is a dependency of glutin 0.19?

• Pro: They are frequently updated in lock-step anyway, so users might have an easier time figuring out and specifying the correct dependencies.

• Con: If there was a breaking change in only one of winit or glutin that does not require a corresponding change in the other, the locked version bump might not be strictly necessary as per semver.

On the other hand I think that documenting and (as dependencies) specifying a range of (in fact) compatible versions in this case should be easy enough.

Example

To demonstrate the case where winit 0.20 and 0.21 were breaking changes, but glutin 0.20 and 0.21 just bumped version in tandem.

Glutin docs:

Glutin version 0.21 is backwards-compatible with versions 0.20 and 0.19.

User dependencies:

[dependencies]
glutin = ">= 0.19.4, < 0.22"
winit = "0.21.1"

What do you think?

[felixrabe]

(For the colors above see https://stackoverflow.com/a/41247934.)

[francesca64]

While I agree that the differing version numbers aren't pretty, it feels silly to me to artificially force them to match. For one thing, I feel it's more in the spirit of the Rust philosophy to have version numbers be transparent and explicit. (The other big concern is that it's more hassle for me to coordinate releases!)

The reason releases tend to happen in lockstep is because glutin gets almost no activity, i.e. after I merge rust-windowing/glutin#1029 a new glutin release will probably be made. If versions were synchronized, then winit would have to bump ahead by two versions, which would be confusing to anyone using winit without glutin (of which there are increasingly many).

On that same note, you could say that any other context crates that use winit should be synchronized... winit and glutin aren't really married; they just happen to spend a lot of time together. The fact that the current version numbers are only off by 1 is a coincidence, which I think belies how much they're able to progress separately.

[felixrabe]

Sounds good to me. Unless there is a huge crowd in favor of my proposal showing up very soon, then this can be closed :)

[Osspial]

It's worth noting that cargo supports non-exact dependencies. Once winit hits 1.0, it may be worth setting glutin's winit dependency to be ~1 so that we no longer have to manually update glutin's dependencies.

[felixrabe]

@Osspial Note that my issue was about the user of glutin and winit having to specify different versions for each, while your comment seems to be about glutin specifying its dependency on winit.

But now reflecting on it (coming from the issue comment linking to glutin docs section that originates from winit docs...) my / this issue might be resolved by the user just using glutin and using any winit functionality via what glutin re-exports.

[mitchmindtree]

Another issue with this is that, while glutin is perhaps currently the most popular downstream user of winit, winit was separated from glutin in the first place in order to support other graphics backends. For example, the vulkano org have a crate that allows for using a vulkano instance within a winit window and has nothing to do with glutin at all. If winit was designed solely for glutin I think I'd consider this more closely, but I don't think it makes a great deal of sense as winit isn't inherently tied to glutin (even if glutin is tied to winit). Thanks for the issue regardless @felixrabe!

this issue might be resolved by the user just using glutin and using any winit functionality via what glutin re-exports.

Yes I believe it is glutin's goal to re-export everything from winit that could be needed by a downstream user. If you're missing access to something in winit through glutin, an issue would be very welcome at the glutin crate!