Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I don't think you should be making some releases to crates #1524

Closed
cdecompilador opened this issue Nov 12, 2022 · 4 comments
Closed

I don't think you should be making some releases to crates #1524

cdecompilador opened this issue Nov 12, 2022 · 4 comments

Comments

@cdecompilador
Copy link

cdecompilador commented Nov 12, 2022

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.

@kchibisov
Copy link
Member

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.

@kchibisov
Copy link
Member

Also, if could point to a half working glutin release, let me know, but please, say what is not working.

@cdecompilador
Copy link
Author

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

@kchibisov
Copy link
Member

kchibisov commented Nov 12, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants