update change log for v1.1.6

[countvonzero]

Motivation

keep CHANGELOG consistent for cherrypick

[codecov]

Codecov Report

Merging #5023 (b96b04d) into develop (d204c59) will decrease coverage by 0.1%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           develop   #5023     +/-   ##
=========================================
- Coverage     77.1%   77.1%   -0.1%     
=========================================
  Files          254     254             
  Lines        30363   30363             
=========================================
- Hits         23437   23431      -6     
- Misses        5409    5414      +5     
- Partials      1517    1518      +1     

see 2 files with indirect coverage changes

[dshulyak]

i don't understand why is it updated. v1.1.6 doesn't really follow any of the workflows specified in the repository. it for some reason also overwrote v1.1.5 release. i think it would better if we stick exactly to workflow

as this change was cherry picked to v1.1 branch and released from it, new section should have been added with v1.1.6 that would contain only new change. in develop branch this hotfix will be kept in UNRELEASED until we release a branch from develop

[countvonzero]

as this change was cherry picked to v1.1 branch and released from it, new section should have been added with v1.1.6 that would contain only new change. in develop branch this hotfix will be kept in UNRELEASED until we release a branch from develop

but if we don't port the cherrypicked changelog into develop, and rebase from develop, the CHANGELOG is just inconsistent. for example, v1.1.3 (also cherrypicked) is forever lost in the changelog. is that the intended effect?

[dshulyak]

but if we don't port the cherrypicked changelog into develop, and rebase from develop, the CHANGELOG is just inconsistent. for example, v1.1.3 (also cherrypicked) is forever lost in the changelog. is that the intended effect?

so when you released cherry-pick from v1.1 it is forerved inconsistent with develop, yes this is intended. for example there could be v1.1 and v1.2, they will naturally branch out at some point if we will want to maintain v1.1

the suggested full workflow is that changelog is maintained in release branch, so now you did v1.1.6, next there should be v1.1.7 that will be on top of v1.1.6, so changelog in v1.1 can be always "sequential"

simplified workflow allows to rebase on develop and lose "sequantial" changelog. i imagined that we will do it only for branches, but it honestly doesn't matter that much if v1.1.7 will be right on top of v1.1.5, and loose v1.1.6