Version churn (v2)

[Jasper-Bekkers]

Hi all,

While most of this already got discussed in #1720, after that issue got closed another 6 versions got released on crates.io, 3 of which were in September alone. Since this crate is becoming one of the staple crates of the Rust ecosystem on windows it's becoming quite a burden to keep updating the entire ecosystem every time a windows-rs release comes out.

By now, quite a few fundamental crates rely on this library, things like winit, tao, tauri, cpal and for windows-sys, parking_lot, mio, uuid etc. All of these are rather divided now about which windows version they should be on.

Since the regular C/C++ windows api barely changes these days (or at least, the fundamentals are more or less fixed), it seems rather counterintuitive that this crate needs so much releases.

I understand that this crate is mostly still getting into shape and settling in, however, it feels like it's maybe time for a slower, more consistent release schedule for this crate? Maybe pushing out a new release every quarter (if needed) or something to that effect?

[kennykerr]

I generally shoot for a 6-month cycle for the windows-sys crate and a 1-month cycle for the windows crate, unless I get a request for an additional release. Folks seem to be happy with the cadence of the windows-sys crate.

I'm also happy to slow down the cadence for the windows crate if that would be helpful.

[glandium]

The problem is not the release schedule per se, but the unnecessary bumps in version. 0.42 does have semver incompatible changes compared to 0.36 (removal of features and code, although arguably, AIUI, it wasn't technically possible to do anything with what was removed), but the fact that we went from 0.36 to 0.42 is a reflection on the fact that you're synchronizing all the version numbers in the repository, and semver-incompatible changes in the windows crate (not windows-sys) impact all the others. For instance, I don't see differences in windows-sys between 0.35 and 0.36 that would actually warrant a semver bump, and I think that has been true for most of the crate's history.

The same is true for the windows_* target crates, where, e.g., there haven't been any incompatible change between 0.36 and 0.39, 0.40 (IIRC) only fixed things that were broken in previous versions, likewise for 0.41 and 0.42, and no changes in 0.43.

[kennykerr]

That is no longer the case. Prior and up to 0.36, all the crates were versioned and published in tandem. That is no longer the case. You'll note that windows is currently at 0.43, windows-sys is at 0.42 and both share the same target crate dependencies, all of which are 0.42 because they didn't change between 0.43 and 0.42.

The windows-rs project now also has much better validation and detection for identifying changes that necessitate version bumps that previously required everything to be updated "just in case". So things are getting better, but keep the feedback coming. Much appreciated. 😊

[glandium]

Prior and up to 0.36, all the crates were versioned and published in tandem.

As far as versioning goes, this was actually true prior and up to 0.42. Sure, the intermediate versions of windows-sys weren't published, but they still all received a version bump in sync in the repo. Thank you for having changed that in 0.43.

[Elabajaba]

@jrmuizel what would Mozilla consider to be an acceptable cadence to be able to vendor windows? There's a few large improvements to wgpu's dx12 hal that are blocked/potentially blocked on it not being able to switch from winapi.

[ChrisDenton]

Personally I think it'd be good to split DirectX into a separate crate, perhaps with a faster release cycle. It's sufficiently separate to be its own thing and sufficiently different to need special attention.

[jrmuizel]

@Elabajaba it's not so much the cadence as it is the fracturing of the ecosystem. We really don't want to be vendoring and building multiple copies of windows-rs.

What are the improvements that depend on being able to switch from winapi?

[kennykerr]

Do let me know if there are any issues that are preventing migration from winapi - I should be able to address those - for the most part the windows-rs project provides vastly superior API coverage at this point.

[Elabajaba]

@jrmuizel The ecosystem has already chosen to migrate to windows-rs from winapi, this is about wgpu catching up with what winit/mio/tokio/parking_lot/etc have already done. wgpu already has windows-rs dependencies, they've just held them back so that Mozilla had time to move to windows-rs. You've had 11 months at this point since Mozilla decided to not upgrade parking_lot to figure out how you're going to make the switch.

In terms of what winapi is missing, some obvious huge holes are the lack of variable rate shading support and raytracing support.

[Jasper-Bekkers]

@kennykerr I don't quite understand why these issues keep getting closed almost as fast as they're being raised?

It got brought up again as well here; RustAudio/cpal#726 made particularly painful here because CPAL is using quite a few COM objects which aren't properly represented in windows-sys, and so it'll have a hard time switching to to it.

I'm also happy to slow down the cadence for the windows crate if that would be helpful.

I personally would prefer that, because once a month more or less means updating around 10-20 projects, which in turn means we're always behind massively anyway.

[kennykerr]

I don't quite understand why these issues keep getting closed

I have no objection to slowing down the release cadence. In fact, I'm happy to move to an on-demand model, but there's no actionable work so I closed the issue. Perhaps an FAQ entry about the release policy would help?

Regarding RustAudio/cpal#726, I can appreciate the frustration of dealing with changes but those changes stem from improvements to the Win32 metadata that reflect fixes and improvements to the correctness of the API definitions. We are trying to get to a point where all of the Windows APIs are accurately defined in metadata and then faithfully reproduced in Rust, and other languages. As we get closer to that goal, the churn will slow down and eventually stop altogether.

On the Rust side, I also continue to invest in improving the quality and efficiency of the bindings. That too will eventually slow and stop, but there are still important fixes and improvements to be made.

[kennykerr]

To be clear, I understood the previous issue (#1720) to be about windows-sys and I immediately stopped publishing regular updates of that crate. I understand this issue to be about the windows crate and am, again, happy to stop publishing such frequent updates of this crate as well. Let me know if I've misunderstood either issue. Happy to keep discussing. 😊