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

Version identifier #103

Closed
radarhere opened this issue May 18, 2019 · 5 comments · Fixed by #104
Closed

Version identifier #103

radarhere opened this issue May 18, 2019 · 5 comments · Fixed by #104

Comments

@radarhere
Copy link
Contributor

Raqm makes use of FRIBIDI_MAJOR_VERSION to test the Fribidi version. However, there is no version identifier in raqm to allow others to test it in turn. Are you interested in adding a version identifier to the raqm source?

@hugovk
Copy link
Contributor

hugovk commented May 18, 2019

This would be useful for us to be able to specifically target features by version, rather than making a guess about the existence of an unrelated function (see python-pillow/Pillow#3856 (comment)).

If it can be added, it'd be great to release 0.7 or 0.6.1 with the contents of 0.6 plus the version number, so we can make use of it right away.

Thank you!

@khaledhosny
Copy link
Collaborator

For the use case above, a macro won’t help since you are checking at runtime, so you need something like raqm_version() as well. This still wouldn’t help your case immediately sine the new function wouldn’t be present in older versions any way. The current check is good enough, no API is going to be removed ever.

@hugovk
Copy link
Contributor

hugovk commented May 20, 2019

For the use case above, a macro won’t help since you are checking at runtime, so you need something like raqm_version() as well.

Yes please.

This still wouldn’t help your case immediately sine the new function wouldn’t be present in older versions any way.

Yes, that's why a 0.7 or 0.6.1 release with no other changes (except the version number) would let us target that. For the benefit clean code, it would be ok to exclude those with 0.6, and those who've already upgraded to 0.6 will likely soon upgrade to 0.6+.

The current check is good enough, no API is going to be removed ever.

I admire your optimism :)

In any case, it would still be useful to add a version in the future, so we don't need to make assumptions about the presence of unrelated features when targeting other new features.

Thank you!

@khaledhosny
Copy link
Collaborator

The current check is good enough, no API is going to be removed ever.

I admire your optimism :)

That is not optimism, we don’t remove APIs ever. If an API becomes inadequate for some reason, it gets deprecated and a new API is introduced.

@hugovk
Copy link
Contributor

hugovk commented May 27, 2019

Thank you for adding the version!

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

Successfully merging a pull request may close this issue.

3 participants