Add doc/release-process.md

[jonasnick]

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:

define(_CLIENT_VERSION_MAJOR, 0)
define(_CLIENT_VERSION_MINOR, 99)
define(_CLIENT_VERSION_BUILD, 0)
define(_CLIENT_VERSION_RC, 0)
define(_CLIENT_VERSION_IS_RELEASE, false)

and replace our AC_INIT with

AC_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?

[real-or-random]

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.