Update and release policy

[LucasFA]

Suggestion

This repository has a good cadence, 8 semver-incompatible releases in the last year - as the default in the Rust environment is using Cargo's left-shift. Are all of those truly incompatible?

Building crates depending on these windows crates leads to significant duplication and long compile times. We compile three times each of several windows-* crates as they are required by our own dependencies.

Given this repository does not keep a changelog , and instead relies on git logs without a breaking changes token within them, like conventional commits, I find myself scrambling around releases to see how I can upgrade my dependencies, with no clear indications.

My request therefore is for any of the following policies to be considered:

• Follow a conventional commits or similar policy, in which commits indicate explicitly (preferably in the title, with an exclamation mark) breaking changes. This also integrates naturally into automatic changelog generation and versioning tools.
• Keeping a changelog containing at a minimum deprecation notices or general breaking changes. The keep a changelog recommendation is to keep an unreleased section for unpublished changes to avoid having to revisit history.

If this repository didn't actually hold to cargo's standard of using the left-most digit as a breaking-change indicator - honestly I am surprised by the cadence of this project - then naturally it is also an option to

• Maintain a semantic versioning policy. Breaking changes in new 0.y versions and non breaking in patch releases.

[kennykerr]

Versioning and release processes used by hand-authored crates are not very practical for the windows and windows-sys crates since these crates are generated from metadata which is itself not stable.

https://kennykerr.ca/rust-getting-started/how-are-crates-built.html

So, stabilizing these crates will not happen until the metadata is stable and that won't happen any time soon. Stabilization is a goal I'm working toward, but it will take time.

In the meantime, you can always use the windows-bindgen crate that is used to generate these crates and generate your own private bindings to avoid the versioning issues.

See also #432, #1720, #2156

[LucasFA]

I see. I appreciate you taking the time to explain, thank you for your work. I went and read the issues, but I guess I'll try to upgrade by trial and error for now.

[kennykerr]

Thanks for your understanding - appreciate it. Feel free to reach out if you get stuck.