Merge PR cosmos#4902: Changelog Flow Updates

.github/PULL_REQUEST_TEMPLATE.md

@@ -9,7 +9,7 @@ v    If a checkbox is n/a - please still include it but + a little note why
 - [ ] Linked to github-issue with discussion and accepted design OR link to spec that describes this work.
 - [ ] Wrote tests
 - [ ] Updated relevant documentation (`docs/`)
-- [ ] Added a relevant changelog entry: `clog add [section] [-t <tag>] [-m <msg>]`
+- [ ] Added a relevant changelog entry to the `Unreleased` section in `CHANGELOG.md`
 - [ ] Re-reviewed `Files changed` in the github PR explorer
 
 ______

CHANGELOG.md

@@ -1,6 +1,74 @@
+<!--
+Guiding Principles:
+
+Changelogs are for humans, not machines.
+There should be an entry for every single version.
+The same types of changes should be grouped.
+Versions and sections should be linkable.
+The latest version comes first.
+The release date of each version is displayed.
+Mention whether you follow Semantic Versioning.
+
+Usage:
+
+Change log entries are to be added to the Unreleased section under the
+appropriate stanza (see below). Each entry should ideally include a tag and
+the Github issue reference in the following format:
+
+* (<tag>) \#<issue-number> message
+
+The issue numbers will later be link-ified during the release process so you do
+not have to worry about including a link manually, but you can if you wish.
+
+Types of changes (Stanzas):
+
+"Features" for new features.
+"Improvements" for changes in existing functionality.
+"Deprecated" for soon-to-be removed features.
+"Bug Fixes" for any bug fixes.
+"Breaking" for breaking API changes.
+
+Ref: https://keepachangelog.com/en/1.0.0/
+-->
+
 # Changelog
 
-## 0.36.0
+## [Unreleased]
+
+### Breaking Changes
+
+* (modules) [\#4665](https://github.com/cosmos/cosmos-sdk/issues/4665) Refactored `x/gov` module structure and dev-UX:
+  * Prepare for module spec integration
+  * Update gov keys to use big endian encoding instead of little endian
+* (rest) [\#4783](https://github.com/cosmos/cosmos-sdk/issues/4783) The balance field in the DelegationResponse type is now sdk.Coin instead of sdk.Int
+
+### Features
+
+* (store) [\#4724](https://github.com/cosmos/cosmos-sdk/issues/4724) Multistore supports substore migrations upon load. New `rootmulti.Store.LoadLatestVersionAndUpgrade` method in
+`Baseapp` supports `StoreLoader` to enable various upgrade strategies. It no
+longer panics if the store to load contains substores that we didn't explicitly mount.
+
+### Improvements
+
+* (modules) [\#4762](https://github.com/cosmos/cosmos-sdk/issues/4762) Deprecate remove and add permissions in ModuleAccount.
+* (modules) [\#4760](https://github.com/cosmos/cosmos-sdk/issues/4760) update `x/auth` to match module spec.
+* (modules) [\#4814](https://github.com/cosmos/cosmos-sdk/issues/4814) Add security contact to Validator description.
+* (sdk) [\#4566](https://github.com/cosmos/cosmos-sdk/issues/4566) Export simulation's parameters and app state to JSON in order to reproduce bugs and invariants.
+* (sdk) [\#4640](https://github.com/cosmos/cosmos-sdk/issues/4640) improve import/export simulation errors by extending `DiffKVStores` to return an array of `KVPairs` that are then compared to check for inconsistencies.
+* (sdk) [\#4717](https://github.com/cosmos/cosmos-sdk/issues/4717) refactor `x/slashing` to match the new module spec
+* (sdk) [\#4758](https://github.com/cosmos/cosmos-sdk/issues/4758) update `x/genaccounts` to match module spec
+* (simulation) [\#4824](https://github.com/cosmos/cosmos-sdk/issues/4824) PrintAllInvariants flag will print all failed invariants
+* (simulation) [\#4490](https://github.com/cosmos/cosmos-sdk/issues/4490) add `InitialBlockHeight` flag to resume a simulation from a given block
+  * Support exporting the simulation stats to a given JSON file
+* (store) [\#4792](https://github.com/cosmos/cosmos-sdk/issues/4792) panic on non-registered store
+* (types) [\#4821](https://github.com/cosmos/cosmos-sdk/issues/4821) types/errors package added with support for stacktraces. It is meant as a more feature-rich replacement for sdk.Errors in the mid-term.
+
+### Bug Fixes
+
+* (cli) [\#4763](https://github.com/cosmos/cosmos-sdk/issues/4763) Fix flag `--min-self-delegation` for staking `EditValidator`
+* (keys) Fix ledger custom coin type support bug
+
+## [v0.36.0] - 2019-08-13
 
 ### Breaking Changes
 
@@ -162,12 +230,19 @@
   Replace complex Context construct with a simpler immutible struct.
   Only breaking change is not to support `Value` and `GetValue` as first class calls.
   We do embed ctx.Context() as a raw context.Context instead to be used as you see fit.
-  
+
   Migration guide:
-
-  `ctx = ctx.WithValue(contextKeyBadProposal, false)` ->
-  `ctx = ctx.WithContext(context.WithValue(ctx.Context(), contextKeyBadProposal, false))`
-
+
+  ```go
+  ctx = ctx.WithValue(contextKeyBadProposal, false)
+  ```
+
+  Now becomes:
+
+  ```go
+  ctx = ctx.WithContext(context.WithValue(ctx.Context(), contextKeyBadProposal, false))
+  ```
+
   A bit more verbose, but also allows `context.WithTimeout()`, etc and only used
   in one function in this repo, in test code.
 * [\#3685](https://github.com/cosmos/cosmos-sdk/issues/3685)  Add `SetAddressVerifier` and `GetAddressVerifier` to `sdk.Config` to allow SDK users to configure custom address format verification logic (to override the default limitation of 20-byte addresses).
@@ -222,8 +297,8 @@
   methods.
 * [\#4654](https://github.com/cosmos/cosmos-sdk/issues/4654) validator slash event stored by period and height
 * [\#4681](https://github.com/cosmos/cosmos-sdk/issues/4681) panic on invalid amount on `MintCoins` and `BurnCoins`
-  - skip minting if inflation is set to zero
-* Sort state JSON during export and initialization  
+  * skip minting if inflation is set to zero
+* Sort state JSON during export and initialization
 
 ## 0.35.0
 
@@ -2468,3 +2543,8 @@ BUG FIXES:
 ##### September 22, 2016
 
 * Basecoin compiles again
+
+<!-- Release links -->
+
+[Unreleased]: https://github.com/cosmos/cosmos-sdk/compare/v0.36.0...HEAD
+[v0.36.0]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.36.0

CONTRIBUTING.md

@@ -1,18 +1,19 @@
 # Contributing
 
-- [ADR](#adr)
-- [Pull Requests](#pull-requests)
-  - [Process for reviewing PRs](#process-for-reviewing-prs)
-  - [Updating Documentation](#updating-documentation)
-- [Forking](#forking)
-- [Dependencies](#dependencies)
-- [Testing](#testing)
-- [Branching Model and Release](#branching-model-and-release)
-  - [PR Targeting](#pr-targeting)
-  - [Development Procedure](#development-procedure)
-  - [Pull Merge Procedure](#pull-merge-procedure)
-  - [Release Procedure](#release-procedure)
-  - [Point Release Procedure](#point-release-procedure)
+- [Contributing](#contributing)
+  - [Architecture Decision Records (ADR)](#architecture-decision-records-adr)
+  - [Pull Requests](#pull-requests)
+    - [Process for reviewing PRs](#process-for-reviewing-prs)
+    - [Updating Documentation](#updating-documentation)
+  - [Forking](#forking)
+  - [Dependencies](#dependencies)
+  - [Testing](#testing)
+  - [Branching Model and Release](#branching-model-and-release)
+    - [PR Targeting](#pr-targeting)
+    - [Development Procedure](#development-procedure)
+    - [Pull Merge Procedure](#pull-merge-procedure)
+    - [Release Procedure](#release-procedure)
+    - [Point Release Procedure](#point-release-procedure)
 
 Thank you for considering making contributions to Cosmos-SDK and related
 repositories!
@@ -21,24 +22,27 @@ Contributing to this repo can mean many things such as participated in
 discussion or proposing code changes. To ensure a smooth workflow for all
 contributors, the general procedure for contributing has been established:
 
-1. either [open](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or
-   [find](https://github.com/cosmos/cosmos-sdk/issues) an issue you'd like to help with,
-2. participate in thoughtful discussion on that issue,
-3. if you would then like to contribute code:
-   1. if a the issue is a proposal, ensure that the proposal has been accepted,
-   2. ensure that nobody else has already begun working on this issue, if they have
-      make sure to contact them to collaborate,
-   3. if nobody has been assigned the issue and you would like to work on it
+1. Either [open](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or
+   [find](https://github.com/cosmos/cosmos-sdk/issues) an issue you'd like to help with
+2. Participate in thoughtful discussion on that issue
+3. If you would like to contribute:
+   1. If a the issue is a proposal, ensure that the proposal has been accepted
+   2. Ensure that nobody else has already begun working on this issue, if they have
+      make sure to contact them to collaborate
+   3. If nobody has been assigned the issue and you would like to work on it
       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
-      top of `master`, make some commits, and submit a PR to `master`, - for core developers working within the cosmos-sdk repo,
-      to ensure a clear ownership of branches, branches must be named with the convention `yourname/{issue-}feature-name`.
-   5. include `WIP:` in the PR-title to and submit your PR early, even if it's
-      incomplete, this indicates to the community you're working on something and
-      allows them to provide comments early in the development process. When the code
-      is complete it can be marked as ready-for-review by replacing `WIP:` with
-      `R4R:` in the PR-title.
+      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
+      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
+      it's incomplete as this indicates to the community you're working on
+      something and allows them to provide comments early in the development process
+   6. When the code is complete it can be marked `Ready for Review`
+   7. Be sure to include a relevant change log entry in the `Unreleased` section
+      of `CHANGELOG.md` (see file for log format)
 
 Note that for very small or blatantly obvious problems (such as typos) it is
 not required to an open issue to submit a PR, but be aware that for more complex
@@ -196,16 +200,20 @@ only pull requests targeted directly against master.
 
 ### Release Procedure
 
-- start on `master`
-- 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, use `clog` to prepare the `CHANGELOG.md` and kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks).
-- if errors are found during the simulation testing or if any last minute changes
-need to be introduced, create a new `RC` branch (making sure to increment the `rcN`)
-based off of the current `RC` branch and commit any fixes or changes
-  - the above requires that any commits introduced must also be merged back into `master` 
-- after simulation has successfully completed, create the release branch (`release/vX.XX.X`) from the `RC` branch
-- merge the release branch to `master` to incorporate the `CHANGELOG.md` updates
-- delete the `RC` branches
+- Start on `master`
+- 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`
+- 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 `master`
+  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 `master` to incorporate the `CHANGELOG.md` updates
+- Delete the `RC` branches
 
 ### Point Release Procedure