How to do a Badger Release

LGalatin · May 1, 2020, 5:41pm

Please follow these steps when releasing Badger:

Get the list of all the changes

Check all the changes between the previous release and the release candidate by going to this URL: https://github.com/dgraph-io/badger/compare/vx.x.x…master. Change vx.x.x in the URL as needed, for example v1.6.0. This shows the whole list of commits and code changes since the previous release.

Categorize the changes

Categorize the changes (Feature, Bug, Performance, Not-needed). Try to associate each CHANGELOG line with either the commit SHA or PR number. Specify if there are any breaking changes or if there are any specific enterprise changes. We normally use a google sheet to do this. This sheet should be reviewed by an engineering lead.

Get a summary of user-facing API changes

For a quick summary of user-facing API changes, you diff the go doc for the different versions.

git checkout v1.6.0

go doc -all > /tmp/v1.6.0

git checkout master

go doc -all > /tmp/v2.0.0

cd /tmp

diff -u v1.6.0 v2.0.0

Update, review and merge the CHANGELOG.

Now that we have all the changes (from steps 3 and 4), we can update the CHANGELOG. Please refer to a previous release to get a general idea of the format to follow. Remember to also update the Markdown hyperlinks at the bottom of the CHANGELOG.md file. This looks something like this:

Open a PR to be reviewed and then merge the changes for CHANGELOG.

Make a feature branch

First, make sure your user settings are set up locally (https://help.github.com/en/github/using-git/setting-your-username-in-git) then, make a feature branch

git config --global user.name “Leyla Galatin”

git config --global user.email “leyla@dgraph.io”

git checkout -b “nameoffeaturebranch”.

(e.g., git checkout -b lgalatin/changelog-v2.0.1)

Check the test results

Make sure all the tests pass. Badger tests can be run with ./test.sh. You can also check TeamCity builds for Badger master branch https://teamcity.dgraph.io/viewType.html?buildTypeId=Badger_UnitTests&branch_Badger=&tab=buildTypeStatusDiv

Release Candidate

Please ensure you’re on the correct branch. Every major release has its own branch. V2 has release/v2.0 branch and v1.6 has release/v1.6 branch. All commits should be cherry-picked from the master branch into the correct branch and then the commit on the branch is tagged.

Tag the Git commit for the commit you want to release. Push that tag to GitHub.

git tag v2.0.0-rc4

git push origin v2.0.0-rc4

Draft a pre-release on GitHub.

Go to the Releases page and click on Draft a new release. Direct link: https://github.com/dgraph-io/badger/releases/new
Select the tag: v2.0.0-rc4.
Call the title “BadgerDB v2.0.0-rc4”.
Copy the CHANGELOG entry for the release candidate. You can view the Raw Markdown version to get the correct formatting to paste in.
Check the “This is a pre-release” check box so users know this is not an official release.

Check that users can download the release

mkdir /tmp/mymodule

cd /tmp/mymodule

go mod init mymodule

go get -u -v github.com/dgraph-io/badger/v2@v2.0.0-rc4

Check the go.mod

go.mod file should have the badger dependency with the correct version. Below, you’ll see that it says “v2.0.0”.

$ cat go.mod | grep badger

github.com/dgraph-io/badger/v2 v2.0.0 // indirect

Official Releases

Tag the Git commit for the commit you want to release. Push that tag to GitHub.