Winit: Request to accelerate winit's release schedule

Created on 9 Oct 2020  路  5Comments  路  Source: rust-windowing/winit

There was roughly a 4 month gab between 0.22.1 and 0.23.0. In this period lots of people will be using winit by just adding winit = "0.22.1" or winit = "*" to their projects but will suffer from bugs and issues that have been solved months ago. This is a less than ideal developer experience in my opinion.

Would it be possible to increase the frequency of winit minor and patch releases?

(relevant: semver)

All 5 comments

The release schedule is roughly "whenever someone submits a pull request that bumps the version." Sometimes releases do get held at the last minute for specific things to land, but 0.23.0 was only in that state for about a week I think?

A more formalized process might help, but also feel free to make version-bump pull requests as a downstream user.

In general, if downstream needs release they can always ask. With 0.23.0, release was done when it should be done, since we had breaking updates pending and very massive PR enqueued, which tooked literally a month to review and test. If you look into history the change log was with only minor fixes before I've submitted Wayland changes and new API changes.

So to reduce amount of work for downstream I decided to pack as much breaking changes in one minor release as we can, those changes fixed some usability issues on Wayland, since old fullscreen/monitor API wasn't really working for it...

I don't like keeping meta issues opened around, so I'll close this issue.

If you really want a release and can't stick with some commit from git(cargo has patch section), let us know in #glutin or here. You also have an option with vendoring winit and applying required set of patches for your project.

I'm also a bit biased on when doing releases, since I try to sync them with the largest winit consumer (alacritty), so we (alacritty) will have all the necessary fixes for our next release. I'm not saying that I'll always stick to that, I'm just letting you know, that if some large downstream projects, that is being packaged in some Linux distrubutions/*BSD wants a fixed release they can stick to, they should ask us here or on a mentioned channels. For some small projects it's likely fine to use git versions( I was using it myself for some time with my small projects using winit + glutin).

I'd also add one thing, I personally try to avoid minor bumping winit unless it's really necessary, since it generates additional hassle for everyone, since you should release 2 crates(winit and glutin), and other downstream libraries should update as well, which is just time...

winit may do bug fix branches, and established some release process, but I'm not sure that it's really necessary at this point, if it'll start bringing issues due to frequency of winit's breaking API changes, I'd consider doing so, right now it's pretty chill in my opinion and updates are minor for downstream.

If you really want a release and can't stick with some commit from git(cargo has patch section), let us know in #glutin or here.

I'd love to see a new release. There are quite a few bug fixes that I think are important in master, but I see that there are also breaking changes.

I don't see anything major tbh, and you always have an option to refer to git commit. As for the next release, I'd rather take more breaking changes into it, than doing a bunch of small bumps.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

k0nserv picture k0nserv  路  3Comments

rukai picture rukai  路  4Comments

ryanisaacg picture ryanisaacg  路  3Comments

chrisduerr picture chrisduerr  路  4Comments

felixrabe picture felixrabe  路  4Comments