I don't think you should be making some releases to crates
cdecompilador opened this issue · 4 comments
Since 0.29 you have been making some non-working/half-working releases to crates that might confuse users that just do cargo add glutin, I think 0.29 shouldn't have gone past beta until the base api is complete, everything is documented, and examples are extensive and compile (which they don't on the release).
In my opinion the best move would have been to keep 0.29 on beta until everything is done, receive some feedback and make a proper release with even a migration guide for the users.
This is just my impression after having a very hard time trying to migrate something.
Since 0.29 you have been making some non-working/half-working releases to crates that might confuse users that just do cargo add glutin, I think 0.29 shouldn't have gone past beta until the base api is complete, everything is documented, and examples are extensive and compile (which they don't on the release).
glutin 0.30.0 was in betas for like 3 month, all feedback was collected and various maintainers were involved during that. Coming from nowhere and telling how to manage stuff is not good behavior, where were you during glutin betas? Were you provided any feedback? The crate situation was brought up lots of time.
The current glutin API is complete, various crates such as alacritty are already ported to it.
In my opinion the best move would have been to keep 0.29 on beta until everything is done, receive some feedback and make a proper release with even a migration guide for the users.
We are already past this stage, we've gone though 3 betas.
This is just my impression after having a very hard time trying to migrate something.
I'm sorry, what else do you want and feel incomplete? There's even a glutin-winit shim now to help migrating. I'm not sure what else you'd need? There's not that much to write in examples, since most stuff is show cased in winit, and glutin is about getting platform setup, nothing more. Nothing special to show case. By now new have 2 examples, one showing the window on desktop + android, and the other showing how to use EGL device API for offscreen rendering.
This is just my impression after having a very hard time trying to migrate something.
I'm not sure what you've failed to port. Most crates I'm aware of (egui, iced), don't have issues with migrating old code to new from what I've seen in their PRs.
Also, if could point to a half working glutin release, let me know, but please, say what is not working.
The last release 0.30.1 example doesn't work for example.
If you are refering to half-working as feature-missing I would note #1449 #1448 some api discussions that should had happened pre-release like the glutin / glutin-winit split, a lot of closed issues (bug/api redesign) that happened post-release of 0.29.
It's just my perspective, also I'd have made a major version release instead of 0.29, the breaking changes are that big that maybe you should have prepared to make a 1.0, instead of 0.29 working on a 1.0-beta with a very well documented migration guide would have helped until everything was at a decent state
If something doesn't work open an issue showing what exactly is not working for you? I might have missed something during tests, but I'm just a human in the end, and not a robot that could test GUI GL platform automatically with little to no resources. I test us much as I can on my hardware. And given it's a GL platform my hardware isn't your hardware.
I would note #1449 #1448 some api discussions that should had happened pre-release like
That was brought multiple times during development and betas, no-one is capable of maintaining those platforms. Old backends were broken anyway and were straight segfaulting on iOS, but you ofc know better. I've opened issues only to state a fact that during betas no one bothered to deal with them.
glutin / glutin-winit split
You seem to not looked at the code and philosophy behind glutin 0.30. It was written around raw-window-handle. The glutin-winit crate is solely to help people migrate their single file examples using glutin with winit. So the other crate was written by needs of downstream to not repeat the shim we have.
Glutin 0.29.0 is not a working crate, it wasn't maintained for 2 years at least with issues that can't be solved without breaking it. Some of its handling is error prone and unsafe in a first place, while API saying it's safe.
I'd suggest you to just open issues if you have encountered issues with the new glutin describing what is not working. Otherwise it is all pointless.