Introduce symbol to get version of library #914
Conversation
| @@ -1,5 +1,13 @@ | |||
| AC_PREREQ([2.60]) | |||
| AC_INIT([libsecp256k1],[0.1]) | |||
| AC_PREREQ([2.69]) | |||
There was a problem hiding this comment.
Why is this necessary?
There was a problem hiding this comment.
This was to do what bitcoin core was doing for version and release management, I think I can improve it though
There was a problem hiding this comment.
I think we shouldn't increase it to 2.69 without a good reason. I'm not sure if it really works with 2.60 but it's not a disaster if it fails.
| AC_PREREQ([2.69]) | ||
|
|
||
| define(_LIBSECP256K1_VERSION_MAJOR, 0) | ||
| define(_LIBSECP256K1_VERSION_MINOR, 8) |
There was a problem hiding this comment.
Should be 99 according to the preliminary plan (#856). I didn't have a particular reason for this besides matching Bitcoin Core's approach. But if I understand this PR correctly , secp256k1_version doesn't include _LIBSECP256K1_VERSION_IS_RELEASE. If minor version was 99 for non-releases, secp256k1_version can be used to distinguish between releases and non-releases.
There was a problem hiding this comment.
Yeah - I picked 0.8 to provide additional headroom for breaking API changes before stabilization.
0.8 could be cut as a branch now-ish
0.9 would represent a nearly complete API and allow for stabilization from 0.9 -> 0.9.9
and 1.0 would reflect final API / ABI
|
Closing due to no activity. It can always be reopened. |
This adds additional logic to autoconf for future support of versioning.
I picked 0.8 fairly arbitrarily to represent unstable, 0.9 would be the API stabilization series working to a 1.0
Also a NULL terminated C-String is exported with the symbol
secp256k1_versionthat matches.