-
Notifications
You must be signed in to change notification settings - Fork 429
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
Consider making a glad2 release / tag #382
Comments
You're right there is no reason that prevents a release, I was just never sure if I wanted to change the API again, but after such a long time I haven't found a good reason to do so. I will make a release in the upcoming days, it will probably packaged as glad2 not glad with version 2.0, because there is nothing wrong with glad1 and would break people's setups that pull from pypi |
Well, there's one thing that's actually bugging me about glad which might require an API change to resolve fully. I'll open a separate issue to discuss this. |
Right, with that out of the way, what needs to be done for a release? |
A little bit of cleanup, I'll get it done today. |
Tag is pushed, released on pypi as |
Let's hope I didn't break everything in the last few commits... |
Still seems to work for me, for what it's worth. I've also packaged glad2 as an |
After weighing the pros and cons of all of the alternatives out there, I've found that
glad2
, even in its beta state, is the only viable replacement forlibepoxy
in my own production library, libplacebo. The upcoming libplacebo v5.288, slated for release sometime in the next week or two, will be the first major libplacebo release to depend on glad2 internally, currently in soft-bundled form via git submodule.However, this is a bit awkward for distros, since libplacebo source tarballs do not contain bundled submodules, seeing as distros tend to be expected to package dependencies separately. However, it's a bit unfortunate that glad2 does not have a stable way of referring to it other than pinning some arbitrary git commit. I rather doubt most distros will be willing to package some random beta branch with no tag or version number.
Given that glad2 in its current state is, in my estimation, usable enough to be used in production code, I think it wouldn't be too far off the mark to consider just making a proper release that I can depend on. Or, failing this, what do you think urgently needs to be addressed before the first
2.0
tag?The text was updated successfully, but these errors were encountered: