Introduce symbol to get version of library #914

1. 
   rickmark commented at 7:54 am on March 26, 2021: none

   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_version that matches.

2. Introduce symbol to get version of library 1446af401e
3. rickmark cross-referenced this on Mar 26, 2021 from issue Create symbol to get the version of this library by rickmark
4. in configure.ac:1 in 1446af401e

   0@@ -1,5 +1,13 @@
   1-AC_PREREQ([2.60])
   2-AC_INIT([libsecp256k1],[0.1])
   3+AC_PREREQ([2.69])
   

   ---

   ---

   

   real-or-random commented at 8:22 am on March 26, 2021:

   Why is this necessary?

   ---

   

   rickmark commented at 4:35 pm on March 26, 2021:

   This was to do what bitcoin core was doing for version and release management, I think I can improve it though

   ---

   

   real-or-random commented at 5:45 pm on March 26, 2021:

   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.
5. in configure.ac:4 in 1446af401e

   0@@ -1,5 +1,13 @@
   1-AC_PREREQ([2.60])
   2-AC_INIT([libsecp256k1],[0.1])
   3+AC_PREREQ([2.69])
   4+
   5+define(_LIBSECP256K1_VERSION_MAJOR, 0)
   6+define(_LIBSECP256K1_VERSION_MINOR, 8)
   

   ---

   ---

   

   jonasnick commented at 1:45 pm on March 26, 2021:

   Should be 99 according to the preliminary plan (https://github.com/bitcoin-core/secp256k1/issues/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.

   ---

   

   rickmark commented at 4:38 pm on March 26, 2021:

   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

6. real-or-random added the label feature on May 9, 2023
7. 
   real-or-random commented at 2:42 pm on May 9, 2023: contributor

   Closing due to no activity. It can always be reopened.
8. real-or-random closed this on May 9, 2023

   ---

Contributors
rickmark real-or-random jonasnick

Labels
feature