Closed haasn closed 2 years ago
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 pip install --user glad
.
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.
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?
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.
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 rpm
file: https://build.opensuse.org/package/show/home:haasn/python-glad2
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?