You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, AFAIK there is no simple library version define that a downstream could utilize to adapt to API changes in liboqs: The only define there is is "OQS_VERSION_TEXT" and I'm not sure that's making it sufficiently easy to adapt a downstream's code to liboqs capabilities: The goal of (and one purpose for) oqsprovider is to build against all versions of liboqs, so a simple-to-use code-level library version test facility should be there, e.g. similar to what we have in openssl. Worthwhile a separate issue/PR or simple enough to do as part of this PR? If the latter, the corresponding oqsprovider update could be done as a "-tracker" update as this is an API-changing PR (either way).
Currently, AFAIK there is no simple library version define that a downstream could utilize to adapt to API changes in
liboqs
: The only define there is is "OQS_VERSION_TEXT" and I'm not sure that's making it sufficiently easy to adapt a downstream's code toliboqs
capabilities: The goal of (and one purpose for)oqsprovider
is to build against all versions ofliboqs
, so a simple-to-use code-level library version test facility should be there, e.g. similar to what we have in openssl. Worthwhile a separate issue/PR or simple enough to do as part of this PR? If the latter, the correspondingoqsprovider
update could be done as a "-tracker" update as this is an API-changing PR (either way).Originally posted by @baentsch in #1919 (comment)
The text was updated successfully, but these errors were encountered: