ibp-release-management.md

Release Management

Goals

We need to release our tools and libraries in a way that is easy to use and contribute.

• github.com for issues and pull requests
• git for version control
• Git branching model
• Git Release management[?]

Branch vs Release

Git Branching Model

Branches:

• master
  • production ready, latest stable release
  • default branch for git clone
  • merge from hotfix or release branches
  • no PRs?
• hotfix branches
  • r0.1.0[-hotfix1]
  • bug fixes to master
  • merge from master
• release branches
  • r0.1.0[-rc1] - release candidate
  • r0.2.0 - release branch
  • allows for bug fixes to be applied to a release
  • merge from develop
• develop (could be called next)
  • latest development changes
  • merge from hotfix (forward-porting)
  • merge from feature branches
  • clone this branch for small changes and bug fixes
• feature branches
  • new features in development that contain breaking changes
  • merge bugs from develop (from time to time, prior to merge to develop)

Git Release

Do we need this? We are not proposing to distribute binaries, so we don't need to tag releases. We should ship bootless binaries (with versions to match upstream)

Resources

• https://nvie.com/posts/a-successful-git-branching-model/
• https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository?tool=webui
• https://github.com/mobify/branching-strategy/blob/master/release-deployment.md

Creating a Release branch from develop

Make sure you are on the develop branch
Select branch dropdown and type in the name of the new release.
Select Create branch < BRANCHNAME > from develop

Merging the release branch into main

Click Open Pull Request

Then save the PR

Request a review from a core developer

A few notes from me:

• I think we should definitely have release tags, and GitHub releases with auto-generated list of commit messages from the last release until the current one. It's great for reference. main should be the release branch.
• Using slashes in branch names such as hotfix/some-hotfix-name or feature/feature-name displays very fine on some UI tools such as Sourcetree. This way one is able to display all hotfixes/features/etc. under a directory on the UI.
• Do we have to prefix branch/tag names with r? I saw v before (Parity uses it), but I think it's unnecessary. Plain version number is enough imo.
• Feature branches and and any other branches that branch off from main or develop should always be kept rebased on the origin branch so that we keep the correct history of commits when we merge.
• Squashing commits on PRs to a single commit is useful and clean in most cases.
• Following the previous, and I know I violated this one quite a bit before, but PRs should small when possible.

I agree, tags are a requirement to trigger a release - we can have github workflows to automate a release as soon as a tag is pushed to the main repo. As an example if useful here

In terms of the flow to create a tag i took some ideas from the gitflow example to this script here

There is also a similar script in polkadot main repo here to automate tags creation.

ok, moved this to ibp-network/ibp-monitor#60