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

Consider making a glad2 release / tag #382

Closed
haasn opened this issue Oct 13, 2022 · 7 comments
Closed

Consider making a glad2 release / tag #382

haasn opened this issue Oct 13, 2022 · 7 comments

Comments

@haasn
Copy link
Contributor

haasn commented Oct 13, 2022

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 for libepoxy 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?

@Dav1dde
Copy link
Owner

Dav1dde commented Oct 13, 2022

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.

@haasn
Copy link
Contributor Author

haasn commented Oct 14, 2022

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.

@haasn
Copy link
Contributor Author

haasn commented Oct 21, 2022

Right, with that out of the way, what needs to be done for a release?

@Dav1dde
Copy link
Owner

Dav1dde commented Oct 21, 2022

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.

@Dav1dde
Copy link
Owner

Dav1dde commented Oct 21, 2022

Tag is pushed, released on pypi as glad2.

@Dav1dde Dav1dde closed this as completed Oct 21, 2022
@Dav1dde
Copy link
Owner

Dav1dde commented Oct 21, 2022

Let's hope I didn't break everything in the last few commits...

@haasn
Copy link
Contributor Author

haasn commented Oct 21, 2022

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

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

No branches or pull requests

2 participants