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

Backward compatiblity? #23

Open
redragonx opened this issue Mar 19, 2017 · 2 comments
Open

Backward compatiblity? #23

redragonx opened this issue Mar 19, 2017 · 2 comments

Comments

@redragonx
Copy link
Contributor

How should we handle multiple libsodium versions? Do we even care?

@silkeh
Copy link
Contributor

silkeh commented Mar 20, 2017

The main problem I see is that Go doesn't really have any way to handle a build against a different library version. I see three ways of doing it:

  • Add wrappers for newer functionality to separate files and use build tags. This creates quite a bit of clutter.
  • Only update the required libsodium version on minor releases (so dependencies can use https://gopkg.in).
  • Aim to replace the libsodium dependency by native functionality altogether.

I think the second option is the way to go, as it would be easier for development.

@redragonx
Copy link
Contributor Author

Push for the 2nd option, people should keep their libraries updated or they can freeze them in their repos.

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

No branches or pull requests

2 participants