Cosmos-sdk: Split "Breaking Changes" in Changelog

[rigelrozanski]

Summary

Basically it's not super ideal for voyager team to have everything lumped into breaking changes, I propose we split "breaking changes" into:

• API Changes (which is implicitly a breaking change)
• Breaking Changes

Problem Definition

Folks who are integrating code to work with SDK applications need a better way of quickly determining if changes need to be made to their codebase when SDK updates are released. We should make it easier then having to sift through the "breaking changes" section.

Proposal

Split "breaking changes" into:

• API Changes (which is implicitly a breaking change)
  
  
  
  • Contains CLI or LCD or Tendermint that has an effect of the integrators needing to change code
  
  
  • More detail within this section as to where applicable, how to make fixes
  
  
  • Clearly linked to an issue #
  
  
• Breaking Changes
  
  
  
  • Everything else
  
  

CC @faboweb @mappum @nylira @ebuchman @cwgoes

---

For Admin Use

• [x] Not duplicate issue
• [x] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[faboweb]

Love it. Let's do it.

[cwgoes]

Do we want to further separate SDK API breaking changes (anyone building on the SDK) from REST/CLI API breaking changes (Gaia users)?

[fedekunze]

Solved