docs: add PR procedure, apply main branch

.github/workflows/docker.yml

@@ -1,10 +1,10 @@
 name: Build & Push
-# Build & Push builds the simapp docker image on every push to master and
+# Build & Push builds the simapp docker image on every push to main and
 # and pushes the image to https://hub.docker.com/r/interchainio/simapp/tags
 on:
  push:
  branches:
- - master
+ - main
  tags:
  - "v[0-9]+.[0-9]+.[0-9]+" # Push events to matching v*, i.e. v1.0, v20.15.10
  - "v[0-9]+.[0-9]+.[0-9]+-rc*" # Push events to matching v*, i.e. v1.0-rc1, v20.15.10-rc5

.github/workflows/lint.yml

@@ -1,14 +1,14 @@
 name: Lint
 # Lint runs golangci-lint over the entire cosmos-sdk repository
-# This workflow is run on every pull request and push to master
+# This workflow is run on every pull request and push to main
 # The `golangci` will pass without running if no *.{go, mod, sum} files have been changed.
 env:
  GOPRIVATE: "github.com/line/*"
 on:
  pull_request:
  push:
  branches:
- - master
+ - main
 jobs:
  golangci:
  name: golangci-lint

.github/workflows/proto-docker.yml

@@ -2,7 +2,7 @@ name: Build & Push SDK Proto Builder
 on:
  push:
  branches:
- - master
+ - main
  paths:
  - "contrib/devtools/dockerfile"
 

.github/workflows/release-sims.yml

@@ -13,7 +13,7 @@ jobs:
  - uses: rokroskar/workflow-run-cleanup-action@master
  env:
  GITHUB_TOKEN: "${{ secrets.TOKEN }}"
- if: "!startsWith(github.ref, 'refs/tags/') && github.ref != 'refs/heads/master'"
+ if: "!startsWith(github.ref, 'refs/tags/') && github.ref != 'refs/heads/main'"
 
  build:
  runs-on: ubuntu-latest

.github/workflows/sims.yml

@@ -9,12 +9,12 @@ on:
 # pull_request:
 # push:
 # branches:
-# - master
+# - main
 
 jobs:
  cleanup-runs:
  runs-on: ubuntu-latest
- if: "!startsWith(github.ref, 'refs/tags/') && github.ref != 'refs/heads/master'"
+ if: "!startsWith(github.ref, 'refs/tags/') && github.ref != 'refs/heads/main'"
  steps:
  - uses: rokroskar/workflow-run-cleanup-action@master
  env:

CONTRIBUTING.md

@@ -35,8 +35,8 @@ contributors, the general procedure for contributing has been established:
  make a comment on the issue to inform the community of your intentions
  to begin work
  4. Follow standard Github best practices: fork the repo, branch from the
- HEAD of `master`, make some commits, and submit a PR to `master`
- - For core developers working within the cosmos-sdk repo, to ensure a clear
+ HEAD of `main`, make some commits, and submit a PR to `main`
+ - For core developers working within the lfb-sdk repo, to ensure a clear
  ownership of branches, branches must be named with the convention
  `{moniker}/{issue#}-branch-name`
  5. Be sure to submit the PR in `Draft` mode submit your PR early, even if
@@ -59,13 +59,6 @@ Other notes:
  A convenience git `pre-commit` hook that runs the formatters automatically
  before each commit is available in the `contrib/githooks/` directory.
 
-## Architecture Decision Records (ADR)
-
-When proposing an architecture decision for the SDK, please create an [ADR](./docs/architecture/README.md)
-so further discussions can be made. We are following this process so all involved parties are in
-agreement before any party begins coding the proposed implementation. If you would like to see some examples
-of how these are written refer to the current [ADRs](./docs/architecture)
-
 ## Pull Requests
 
 To accommodate review process we suggest that PRs are categorically broken up.
@@ -111,22 +104,22 @@ For instance, to create a fork and work on a branch of it, I would:
 - `git remote add origin git@github.com:someone/lfb-sdk.git`
 
 Now `origin` refers to my fork and `upstream` refers to the lfb-sdk version.
-So I can `git push -u origin master` to update my fork, and make pull requests to lfb-sdk from there.
+So I can `git push -u origin main` to update my fork, and make pull requests to lfb-sdk from there.
 Of course, replace `someone` with your git handle.
 
 To pull in updates from the origin repo, run
 
 - `git fetch upstream`
-- `git rebase upstream/master` (or whatever branch you want)
+- `git rebase upstream/main` (or whatever branch you want)
 
-Please don't make Pull Requests from `master`.
+Please don't make Pull Requests from `main`.
 
 ## Dependencies
 
 We use [Go 1.15 Modules](https://github.com/golang/go/wiki/Modules) to manage
 dependency versions.
 
-The master branch of every LFB repository should just build with `go get`,
+The `main` branch of every LFB repository should just build with `go get`,
 which means they should be kept up-to-date with their dependencies, so we can
 get away with telling people they can just `go get` our software.
 
@@ -191,23 +184,52 @@ for tcIndex, tc := range cases {
 
 ## Branching Model and Release
 
-TBD
+User-facing repos should adhere to the trunk based development branching model: https://trunkbaseddevelopment.com/.
+
+Libraries need not follow the model strictly, but would be wise to.
+
+The SDK utilizes [semantic versioning](https://semver.org/).
 
 ### PR Targeting
 
-TBD
+Ensure that you base and target your PR on the `main` branch.
+
+All feature additions should be targeted against `main`. Bug fixes for an outstanding release candidate
+should be targeted against the release candidate branch.
 
 ### Development Procedure
 
-TBD
+- the latest state of development is on `main`
+- `main` must never fail `make lint test test-race`
+- `main` should not fail `make lint`
+- no `--force` onto `main` (except when reverting a broken commit, which should seldom happen)
+- create a development branch either on github.com/line/lfb-sdk, or your fork (using `git remote add origin`)
+- before submitting a pull request, begin `git rebase` on top of `main`
 
 ### Pull Merge Procedure
 
-TBD
+- ensure pull branch is rebased on `main`
+- run `make test` to ensure that all tests pass
+- merge pull request (We are using `squash and merge` for small features)
 
 ### Release Procedure
 
-TBD
+- Start on `main`
+- Create the release candidate branch `rc/v*` (going forward known as **RC**)
+ and ensure it's protected against pushing from anyone except the release
+ manager/coordinator
+ - **no PRs targeting this branch should be merged unless exceptional circumstances arise**
+- On the `RC` branch, prepare a new version section in the `CHANGELOG.md`
+ - All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md`
+ - Copy the entries into a `RELEASE_CHANGELOG.md`, this is needed so the bot knows which entries to add to the release page on github.
+- Kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks)
+- If errors are found during the simulation testing, commit the fixes to `main`
+ and create a new `RC` branch (making sure to increment the `rcN`)
+- After simulation has successfully completed, create the release branch
+ (`release/vX.XX.X`) from the `RC` branch
+- Create a PR to `main` to incorporate the `CHANGELOG.md` updates
+- Tag the release (use `git tag -a`) and create a release in Github
+- Delete the `RC` branches
 
 ### Point Release Procedure
 

Makefile

@@ -413,7 +413,7 @@ proto-lint:
  @$(DOCKER_BUF) check lint --error-format=json
 
 proto-check-breaking:
- @$(DOCKER_BUF) check breaking --against-input $(HTTPS_GIT)#branch=master
+ @$(DOCKER_BUF) check breaking --against-input $(HTTPS_GIT)#branch=main
 
 TM_URL = https://raw.githubusercontent.com/tendermint/tendermint/v0.34.0-rc6/proto/tendermint
 GOGO_PROTO_URL = https://raw.githubusercontent.com/regen-network/protobuf/cosmos