cosmos · alexanderbez · Aug 13, 2019 · Aug 14, 2019
diff --git a/.clog.yaml b/.clog.yaml
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.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
 
 ______

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,6 +1,50 @@
+<!--
+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]
+
+## [v0.36.1] - 2019-08-TBD
+
+### Bug Fixes
+
+* (baseapp) [\#4903](https://github.com/cosmos/cosmos-sdk/issues/4903) Various height query fixes:
+  * Move height with proof check from `CLIContext` to `BaseApp` as the height
+  can automatically be injected there.
+  * Update `handleQueryStore` to resemble `handleQueryCustom`
+
+## [v0.36.0] - 2019-08-13
 
 ### Breaking Changes
 
@@ -162,12 +206,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 +273,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 +2519,9 @@ BUG FIXES:
 ##### September 22, 2016
 
 * Basecoin compiles again
+
+<!-- Release links -->
+
+[Unreleased]: https://github.com/cosmos/cosmos-sdk/compare/v0.36.1...HEAD
+[v0.36.1]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.36.1
+[v0.36.0]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.36.0
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,17 +1,18 @@
 # Contributing
 
-* [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)
+  - [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!
@@ -20,25 +21,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
-       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.
+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
+      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
@@ -186,14 +189,22 @@ only pull requests targeted directly against master.
   - merge pull request
 
 ### 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, 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
-  - 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
 
 At the moment, only a single major release will be supported, so all point

diff --git a/baseapp/baseapp.go b/baseapp/baseapp.go
@@ -516,6 +516,15 @@ func handleQueryStore(app *BaseApp, path []string, req abci.RequestQuery) abci.R
 
 	req.Path = "/" + strings.Join(path[1:], "/")
 
+	// when a client did not provide a query height, manually inject the latest
+	if req.Height == 0 {
+		req.Height = app.LastBlockHeight()
+	}
+
+	if req.Height <= 1 && req.Prove {
+		return sdk.ErrInternal("cannot query with proof when height <= 1; please provide a valid height").QueryResult()
+	}
+
 	resp := queryable.Query(req)
 	resp.Height = req.Height
 
@@ -566,6 +575,10 @@ func handleQueryCustom(app *BaseApp, path []string, req abci.RequestQuery) (res
 		req.Height = app.LastBlockHeight()
 	}
 
+	if req.Height <= 1 && req.Prove {
+		return sdk.ErrInternal("cannot query with proof when height <= 1; please provide a valid height").QueryResult()
+	}
+
 	cacheMS, err := app.cms.CacheMultiStoreWithVersion(req.Height)
 	if err != nil {
 		return sdk.ErrInternal(

diff --git a/client/context/query.go b/client/context/query.go
@@ -83,10 +83,6 @@ func (ctx CLIContext) query(path string, key cmn.HexBytes) (res []byte, height i
 		return res, height, err
 	}
 
-	if ctx.Height <= 1 && !ctx.TrustNode {
-		return res, height, errors.New("cannot query with proof when height <= 1; please provide a valid height")
-	}
-
 	opts := rpcclient.ABCIQueryOptions{
 		Height: ctx.Height,
 		Prove:  !ctx.TrustNode,

diff --git a/contrib/devtools/Makefile b/contrib/devtools/Makefile
@@ -42,15 +42,14 @@ mkfile_dir := $(shell cd $(shell dirname $(mkfile_path)); pwd)
 
 TOOLS_DESTDIR  ?= $(GOPATH)/bin
 
-GOLANGCI_LINT   = $(TOOLS_DESTDIR)/golangci-lint
-STATIK          = $(TOOLS_DESTDIR)/statik
-GOIMPORTS       = $(TOOLS_DESTDIR)/goimports
-CLOG            = $(TOOLS_DESTDIR)/clog
-RUNSIM			= $(TOOLS_DESTDIR)/runsim
+GOLANGCI_LINT = $(TOOLS_DESTDIR)/golangci-lint
+STATIK        = $(TOOLS_DESTDIR)/statik
+GOIMPORTS     = $(TOOLS_DESTDIR)/goimports
+RUNSIM			  = $(TOOLS_DESTDIR)/runsim
 
 all: tools
 
-tools: statik clog runsim goimports golangci-lint
+tools: statik runsim goimports golangci-lint
 
 golangci-lint: $(GOLANGCI_LINT)
 $(GOLANGCI_LINT): $(mkfile_dir)/install-golangci-lint.sh
@@ -66,18 +65,13 @@ $(GOIMPORTS):
 	@echo "Get goimports@v0.0.0-20190628034336-212fb13d595e"
 	@go get golang.org/x/tools/cmd/goimports@v0.0.0-20190628034336-212fb13d595e
 
-clog: $(CLOG)
-$(CLOG):
-	@echo "Get clog"
-	@go get github.com/cosmos/tools/cmd/clog
-
 runsim: $(RUNSIM)
 $(RUNSIM):
 	@echo "Get runsim"
 	@go get github.com/cosmos/tools/cmd/runsim
 
 tools-clean:
-	rm -f $(STATIK) $(GOIMPORTS) $(CLOG) $(GOLANGCI_LINT) $(RUNSIM)
+	rm -f $(STATIK) $(GOIMPORTS) $(GOLANGCI_LINT) $(RUNSIM)
 	rm -f tools-stamp
 
 .PHONY: all tools tools-clean
diff --git a/scripts/linkify_changelog.py b/scripts/linkify_changelog.py
@@ -0,0 +1,15 @@
+import fileinput
+import re
+
+# This script goes through the provided file, and replaces any " \#<number>",
+# with the valid mark down formatted link to it. e.g.
+# " [\#number](https://github.com/cosmos/cosmos-sdk/issues/<number>)
+# Note that if the number is for a PR, github will auto-redirect you when you click the link.
+# It is safe to run the script multiple times in succession. 
+#
+# Example:
+#
+# $ python ./scripts/linkify_changelog.py CHANGELOG.md
+for line in fileinput.input(inplace=1):
+    line = re.sub(r"\s\\#([0-9]+)", r" [\\#\1](https://github.com/cosmos/cosmos-sdk/issues/\1)", line.rstrip())
+    print(line)