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

Add release-process.md #964

Merged
merged 4 commits into from
Dec 25, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Makefile.am
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ endif
libsecp256k1_la_SOURCES = src/secp256k1.c
libsecp256k1_la_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/src $(SECP_INCLUDES)
libsecp256k1_la_LIBADD = $(SECP_LIBS) $(COMMON_LIB) $(PRECOMPUTED_LIB)
libsecp256k1_la_LDFLAGS = -no-undefined
libsecp256k1_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_CURRENT):$(LIB_VERSION_REVISION):$(LIB_VERSION_AGE)

if VALGRIND_ENABLED
libsecp256k1_la_CPPFLAGS += -DVALGRIND
Expand Down
24 changes: 23 additions & 1 deletion configure.ac
Original file line number Diff line number Diff line change
@@ -1,5 +1,24 @@
AC_PREREQ([2.60])
AC_INIT([libsecp256k1],[0.1])

# The package (a.k.a. release) version is based on semantic versioning 2.0.0 of
# the API. All changes in experimental modules are treated as
# backwards-compatible and therefore at most increase the minor version.
define(_PKG_VERSION_MAJOR, 0)
define(_PKG_VERSION_MINOR, 1)
define(_PKG_VERSION_BUILD, 0)
define(_PKG_VERSION_IS_RELEASE, false)

# The library version is based on libtool versioning of the ABI. The set of
# rules for updating the version can be found here:
# https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
# All changes in experimental modules are treated as if they don't affect the
# interface and therefore only increase the revision.
define(_LIB_VERSION_CURRENT, 0)
define(_LIB_VERSION_REVISION, 0)
define(_LIB_VERSION_AGE, 0)

AC_INIT([libsecp256k1],m4_join([.], _PKG_VERSION_MAJOR, _PKG_VERSION_MINOR, _PKG_VERSION_BUILD)m4_if(_PKG_VERSION_IS_RELEASE, [true], [], [-pre]),[https://github.com/bitcoin-core/secp256k1/issues],[libsecp256k1],[https://github.com/bitcoin-core/secp256k1])

AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_MACRO_DIR([build-aux/m4])
AC_CANONICAL_HOST
Expand Down Expand Up @@ -381,6 +400,9 @@ AM_CONDITIONAL([ENABLE_MODULE_EXTRAKEYS], [test x"$enable_module_extrakeys" = x"
AM_CONDITIONAL([ENABLE_MODULE_SCHNORRSIG], [test x"$enable_module_schnorrsig" = x"yes"])
AM_CONDITIONAL([USE_EXTERNAL_ASM], [test x"$use_external_asm" = x"yes"])
AM_CONDITIONAL([USE_ASM_ARM], [test x"$set_asm" = x"arm"])
AC_SUBST(LIB_VERSION_CURRENT, _LIB_VERSION_CURRENT)
AC_SUBST(LIB_VERSION_REVISION, _LIB_VERSION_REVISION)
AC_SUBST(LIB_VERSION_AGE, _LIB_VERSION_AGE)

# Make sure nothing new is exported so that we don't break the cache.
PKGCONFIG_PATH_TEMP="$PKG_CONFIG_PATH"
Expand Down
12 changes: 12 additions & 0 deletions doc/CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
# Changelog

This file is currently only a template for future use.

Each change falls into one of the following categories: Added, Changed, Deprecated, Removed, Fixed or Security.

## [Unreleased]

## [MAJOR.MINOR.PATCH] - YYYY-MM-DD

### Added/Changed/Deprecated/Removed/Fixed/Security
- [Title with link to Pull Request](https://link-to-pr)
14 changes: 14 additions & 0 deletions doc/release-process.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
# Release Process

1. Open PR to master that
1. adds release notes to `doc/CHANGELOG.md` and
Comment on lines +3 to +4
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In several projects, I've found it quite painful to write all the release notes at once when we actually do a release (the burden of writing the release notes falls on the guy who publishes the release and needs to document other people's additions to the codebase).

Something that worked much better for me was to incrementally update the future release notes: each PR to master that will impact the next release should update the future release notes. This way when we want to publish a release, we only need to do a bit of clean-up, but the release notes are already written and up-to-date. It needs a bit of effort at first to remind contributors to do it, but in the end we usually end up with better release notes.

Feel free to ignore if you think that doesn't make sense for this project, but I felt it was worth sharing in case it can be helpful.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in principle I agree but I'm not really sure. My experience in this repo is that it happens quite often that you ask a contributor to fix a nit before you ACK and then the PR is stalled for months. ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree on @real-or-random's point but we can still remind regular contributors to do this. I wouldn't want to force this on irregular contributors because it's additional work that discourages from contributing PRs in the first place. We could add a pull request template that optionally requests a changelog update.

One significant downside of this is that pull requests would all edit similar space in the same file which, when one PR is merged, would require rebasing every other PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One significant downside of this is that pull requests would all edit similar space in the same file which, when one PR is merged, would require rebasing every other PR.

Apparently that's a real problem which led to a "crisis" in the GitLab project and needs an entirely non-trivial solution:
https://about.gitlab.com/blog/2018/07/03/solving-gitlabs-changelog-conflict-crisis/

I think then the maintainers should create the changelog... I suppose it will be easier for everyone (including maintainers).

Copy link
Contributor

@sipa sipa Dec 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bitcoin Core uses doc/release-notes-<PRNUMBER>.md files which are added by individual PRs, and are then merged into a release release-notes.md by maintainers (not suggesting we do that to; I think the rate of changes here is low enough that maintainers can just keep track of it).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for reference, here's some docs on the process:
https://github.com/bitcoin/bitcoin/blob/23ae7931be50376fa6bda692c641a3d2538556ee/doc/release-process.md#write-the-release-notes
https://github.com/bitcoin/bitcoin/blob/23ae7931be50376fa6bda692c641a3d2538556ee/doc/release-notes.md

This has some helpful notes, e.g., a script to generate a (draft) changelog from git history. This may be helpful to us.

2. if this is **not** a patch release, updates `_PKG_VERSION_{MAJOR,MINOR}` and `_LIB_VERSIONS_*` in `configure.ac`
2. After the PR is merged,
* if this is **not** a patch release, create a release branch with name `MAJOR.MINOR`.
Make sure that the branch contains the right commits.
Create commit on the release branch that sets `_PKG_VERSION_IS_RELEASE` in `configure.ac` to `true`.
* if this **is** a patch release, open a pull request with the bugfixes to the `MAJOR.MINOR` branch.
Also include the release note commit bump `_PKG_VERSION_BUILD` and `_LIB_VERSIONS_*` in `configure.ac`.
4. Tag the commit with `git tag -s vMAJOR.MINOR.PATCH`.
5. Push branch and tag with `git push origin --tags`.
6. Create a new GitHub release with a link to the corresponding entry in `doc/CHANGELOG.md`.