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. 😊

[Jasper-Bekkers]

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?

Thanks @kennykerr for clearing things up, and thanks for being willing to slow down windows-rs's release cadence a bit!

[MarijnS95]

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.

@ChrisDenton side-note: we're also interested in the latest DirectX bindings as those in the SDK (and what windows(-sys) ultimately ends up being generated from) are just too old; at the same time we want to use the latest Agility SDK headers.

Fortunately all support should be in place for individual "chunks of Windows" to release their metadata bindings, which is what I've (t)asked @riverar to take care of in microsoft/DirectX-Headers#79. Once that's done I intend to ask @kennykerr how to set this up on the Rust side ¹, including where to host the generated code and how/who to publish it.
(Perhaps we can already kick-start that or piggy-back on an existing issue, feel free to click "reference in new issue" on this comment!)

At that point I think it's fine to leave the older SDK bindings in the windows crate while also providing a separate crate that provides the latest (not available by default unless the Agility SDK is added) DX12 bindings (which hopefully somehow shares its underlying types with the windows crate through a dependency).

Footnotes

1. Collecting a bunch of links so that I don't have to keep searching for them:

   • https://github.com/microsoft/win32metadata/issues/998
   • https://github.com/microsoft/windows-rs/issues/1856
   • https://github.com/riverar/washington-rs
   ↩

[est31]

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.

I understand that such bugfixes sometimes "break" the API, but I think there are ways to address these issues without requiring breaking semver releases: if struct FooBar had a buggy function foo that needs to take three parameters instead of two, then what about adding a foo2 function or similar? Then when the next semver breaking release is scheduled, you can apply the changes to foo and remove foo2. Most users probably don't care anyway as they use different APIs. This would be semver compatible and would give you more control over when to do a semver breaking release.

[AmionSky]

What about issues like #2138? Will we need to wait 6 months for the fix to come out cause it's a semver breaking change?

[kennykerr]

Will we need to wait 6 months for the fix to come out cause it's a semver breaking change?

Each release is currently a semver breaking change until we reach version 1.

What about issues like #2138?

As I mentioned #2156 (comment) we are switching to an on-demand model, so if there is a need for an update I'll go ahead and publish a new version but won't simply publish new versions on a regular basis. Naturally, the frequency of update requests for windows is going to outpace windows-sys since the former has a much broader applicability and covers far more APIs that are likely to need servicing.

[glandium]

It appears e68424c bumped the versions of the target crates to 0.43.0 for no reason...

[kennykerr]

#2133 added imports to the target libs.

[glandium]

Adding imports is not a semver incompatible change.

[glandium]

That is, this could have been updated to 0.42.1 rather than 0.43.0

[kennykerr]

Ah that's a good point. I can get that fixed up. Can you open a new issue so I don't forget?