Add doc/release-process.md #856

1. 
   jonasnick commented at 10:46 pm on December 4, 2020: contributor

   On our path towards a 1.0 release it would help to start with a 0.1 release soon. Ideally, we’d do this in a systematic way and first discuss how we want the process to look like initially.

   It would make sense for the process to be similar to Bitcoin Core’s. Here are some suggestions, based on my understanding of bitcoin-maintainer-tools/make-tag.py and bitcoin/doc/release-process.md.

   We would copy the start of Core’s configure.ac into ours:

   0define(_CLIENT_VERSION_MAJOR, 0)
   1define(_CLIENT_VERSION_MINOR, 99)
   2define(_CLIENT_VERSION_BUILD, 0)
   3define(_CLIENT_VERSION_RC, 0)
   4define(_CLIENT_VERSION_IS_RELEASE, false)
   

   and replace our AC_INIT with

   0AC_INIT([libsecp256k1],m4_join([.], _CLIENT_VERSION_MAJOR, _CLIENT_VERSION_MINOR, _CLIENT_VERSION_BUILD)m4_if(_CLIENT_VERSION_RC, [0], [], [rc]_CLIENT_VERSION_RC))
   

   We can print the version at the end of the configure script and a warning if RELEASE is not true.

   Now in order to create a release candidate we

   1. Start writing release notes
   2. Create a corresponding release branch
      1. Create a commit to fix the VERSIONS in configure.ac (including RC=1)
      2. Tag the commit with a version of make-tag.py that’s adapted to libsecp
      3. Create github release
   3. To create a new release candidate repeat steps 2.i through 2.iii
   4. Once we’re happy with the release candidate
      1. Archive the release notes for the new version to doc/release-notes/ (branch master and branch of the release)
      2. Create commit to set IS_RELEASE to true and VERSION_RC to 0
      3. Tag the release
      4. Create a new GitHub release with a link to the archived release notes

   This doesn’t look as simple as I would have hoped, but it’s not terrible. What do you think?

2. 
   real-or-random commented at 1:31 pm on February 1, 2021: contributor

   This doesn’t look as simple as I would have hoped, but it’s not terrible. What do you think?

   I agree with this sentiment.

   I’m not entirely sure about having release candidates. But I think this will help us coordinate testing better. At the moment it’s a little bit arbitrary though the quality is good enough that every state that lands on master is a release in a sense.

   Relation to Core

   We should then think about when the canonical point should be to update the tree in Core

   • Updating the Core tree after a release sounds natural and is certainly a good idea.
   • Updating the Core tree after a RC will get us some more testing (and maybe feedback on the API).

   Versioning Scheme

   An aspect that we should talk about is the versioning scheme. I don’t have a lot of experience in this but libtool can do some rather complex stuff:

   • https://stackoverflow.com/a/20355237
   • https://autotools.io/libtool/version.html

   I wonder how this is related to #817. It’s for sure related to #844, which I’m only realizing now.

3. real-or-random cross-referenced this on Mar 24, 2021 from issue Cut a release of 0.X to support a homebrew formula for libsecp256k1 by rickmark
4. jonasnick cross-referenced this on Mar 26, 2021 from issue Introduce symbol to get version of library by rickmark
5. jonasnick cross-referenced this on Jul 7, 2021 from issue Add release-process.md by jonasnick
6. prusnak cross-referenced this on Jul 20, 2021 from issue secp256k1: replace local version with nixpkgs by prusnak
7. real-or-random closed this on Dec 25, 2021

   ---

Contributors
jonasnick real-or-random