documentation: git branch workflow

README.md

@@ -4,8 +4,6 @@ Neptune-core is the reference implementation for the [Neptune](https://neptune.c
 
 ## Installing
 
-note: We recommend installing the latest release unless you are a developer intending to contribute code.
-
 ### Compile from Source -- Linux Debian/Ubuntu
 
  - Open a terminal to run the following commands.
@@ -15,7 +13,7 @@ note: We recommend installing the latest release unless you are a developer inte
  - Install LebelDB: `sudo apt install libleveldb-dev libsnappy-dev cmake`
  - Download the repository: `git clone https://github.com/Neptune-Crypto/neptune-core.git`
  - Enter the repository: `cd neptune-core`
- - for dev(unstable) skip this step. else for latest release: `git checkout v0.0.5`.
+ - Checkout the release branch `git checkout release`. (Alternatively, for the *unstable development* branch, skip this step.)
 
  - Build for release and put the binaries in your local path (`~/.cargo/bin/`): `cargo install --path .` (needs at least 3 GB of RAM and a few minutes)
 
@@ -28,7 +26,7 @@ With a functioning version of cargo, compilation on Windows should just work out
 - Open PowerShell to run the following commands.
 - Download the repository: `git clone https://github.com/Neptune-Crypto/neptune-core.git`
 - Enter the repository: `cd neptune-core`
-- for dev(unstable) skip this step. else for latest release: `git checkout v0.0.5`.
+- Checkout the release branch `git checkout release`. (Alternatively, for the *unstable development* branch, skip this step.)
 
 - Run `cargo install --path .`
 

developer_docs/git_branches.md

@@ -53,6 +53,27 @@ If the branch exists in a triton/neptune official repo, (as opposed to a persona
 
 So if working on issue `#232` and adding feature *walk_and_chew_gum* one might name the branch `myuser/232_walk_and_chew_gum_pr`.
 
+### release branch
+
+The `master` branch can contain changes that are not compatible with whatever network is currently live. Beta-testers looking for the branch that will synchronize with the network that is currently live need branch `release`. This branch may cherry-pick commits that are meant for `master` so long as they are backwards-compatible. However, when this task is too cumbersome, branch `release` will become effectively abandoned -- until the next network version is released.
+
+#### TestNet Release Protocol
+
+ - Ensure that master builds against crates that live on [crates.io](https://crates.io). In particular, no dependencies on github repositories or revisions.
+ - Update `README.md` in case to make sure the installation instructions are up-to-date.
+ - Ensure that all tests pass.
+ - Bump the version in `Cargo.toml`
+ - Create a commit with the subject line `v0.0.6` (or watever the new version number is) and in the body list all the changes.
+ - Push to `master` on github.
+ - Add a tag marking the current commit with the version:
+   - `git tag v0.0.6` (or whatever the next version is)
+   - `git push --tags`.
+ - Set branch `release` to point to `master`:
+   - `git checkout release`
+   - `git reset master`
+   - `git push`
+ - Consider making an announcement.
+
 # Conventional Commits
 
 It is preferred/requested that commit messages use the [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) format.
@@ -69,29 +90,6 @@ git config --global commit.template /path/to/neptune-core/developer_docs/.gitmes
 
 It can also be added on a per-repository basis by omitting the `--global` flag.
 
-### Release tagging
-
-Every published release of a crate is tagged with the [semver](https://semver.org) version eg `v0.0.5`. Some releases of neptune-core may create a new testnet in which case the testnet identifier is also tagged, eg: `(tag: v0.0.5, tag: alphanet-v5)`.
-
-### Release branch(es)
-
-If any changes/fixes are needed for a published release, then a branch can be created based on the release tag
-for any affected crate(s), and the fix should be placed on that branch. Normally a `hotfix` branch should be created based on the release branch with a corresponding pull-request.
-
-As long as the fix does not require an API change, the crate(s) can be published to crates.io with only a bump to the semver PATCH version.
-
-A neptune-core release branch should be created for each
-release, even if it has no further commits.
-
-The neptune-core `README.md` should likewise be updated with each release to provide instructions for
-checking out and building from the release
-branch.
-
-Additionally a warning shall be placed in the
-README.md that the tip of `master` branch is
-for development and should be considered unstable, along with a link to this document.
-
-
 ## Cargo dependencies
 
 ### For published crate releases
@@ -136,4 +134,4 @@ The [patch section docs](https://doc.rust-lang.org/cargo/reference/overriding-de
 This [blog article](https://gatowololo.github.io/blog/cargo-patch/) is also helpful.
 
 
-Finally, all such temporary patches must be removed before publishing a crate!
+Finally, all such temporary patches must be removed before publishing a crate or issuing a new release!