Changelog chain and submodules

[gavioto]

Sometimes there is a big project (or small) with a lot or several submodules. I'm almost sure that having a CHANGELOG for each submodule is mandatory. But a process or standard to create the 'general' CHANGELOG of the project could be interesting, becuause having to read 10 or 15 CHANGELOG for a project could be tedious.

Is there any recomendation or specification for this?

[turnrye]

This is a problem that is shared in enterprise java projects, with multiple artifacts making up one system. Each artifact is published independently and can be inherited by many different projects (for instance for a group of API classes).

I'm pondering how to handle this.

[gavioto]

What do you think about including an Import referencig a git tag that referers to the version used?

Some examples:

• importing in the main changelog for a specific version using [[Import https://github.com/user/project!tag]] <- search CHANGELOG by default.
• importing local change log [[Import ../sub-module1]]

More advanced tools, like a maven plugin, can merge changelogs when needed, but the specification shouldn't be attached to any specific tool.

[olivierlacan]

Rails runs into this issue. They usually release a list of links to individual module changelogs: http://weblog.rubyonrails.org/2017/6/20/Rails-5-1-2-rc1-has-been-released/

I don't love it. There's no editorial work on the part of the release team or release manager to summarize the overall notable changes for the project. Those exist. They always end up in announcement blog posts from other people.

If this new release of Rails for instance has marquee changes, these should be in the overall project changelog and that changelog should link to individual changelogs.

[gilmrjc]

Maybe tag each entry of the CHANGELOG like the Angular team does:

## 4.3.5 (2017-08-16)

### Bug Fixes

- **core**: forbid destroyed views to be inserted or moved in VC (972538b), closes #18615
- **forms**: re-assigning options should not clear select (a1624f2), closes #18330

This only applies to large codebases, and if you follow #41 any breaking can be like:

- **core(BREAKING)**:

This way you can point to breaking changes inside modules.