Prefix & group changes

[estebanprimost]

This PR:

1. Adds a new option --group=<group_name>, -g <group_name> on change commands, for:

   • Visual prefixing changes. Something like:

   • [geut/chan] Added new options to api.

   • Parse/add group property on every change item, at CHANGELOG.md read time.

   Use it as:

   chan added --group=chan/sub-repo 'New stuff added'

2. Adds a new option --group-changes on release command, that groups changes based on group prefix found on each unreleased change item. If no group prefix is found, change item will be grouped under Core, as first group.

Example: Supose you make next changes on your changelog:

$ chan fixed 'Something on geut/cool-repo group' -g geut/cool-repo
$ chan added 'New thing on geut/cool-repo group' -g geut/cool-repo
$ chan changed 'This brokes something on root base repo'

Now, your changelog should be:

## [Unreleased]
### Added
- [geut/cool-repo] New thing on geut/cool-repo group

### Changed
- This brokes something on root base repo

### Fixed
- [geut/cool-repo] Something on geut/cool-repo group

Release time:

chan release --group-changes 1.0.0

Grouped changelog:

## [Unreleased]

## 1.0.0 - 2018-10-17
### Core
#### Changed
- This brokes something on root base repo

### geut/cool-repo
#### Added
- New thing on geut/cool-repo group

#### Fixed
- Something on geut/cool-repo group

Both options are useful for monorepo changelogs where you might want to group/separate modifications by packages.

[tinchoz49]

This is really cool :+1:

[dpaez]

Looks really interesting! The example is not clear (maybe I'm missing something), but you are calling release two times?

[estebanprimost]

Looks really interesting! The example is not clear (maybe I'm missing something), but you are calling release two times?

My bad, first one was wrong! Fixed now. :+1:

[dpaez]

LGTM 👍 just found some minor typos, also added a possible fix as a suggestion.

[tinchoz49]

Hi everyone!

I really like both features, but I have some thoughts about the output format. It's not compatible with the keep-a-changelog that was the original goal of chan.

the keep a changelog use ### to each type change and we are going to lose the compatibility

## [Unreleased]
### Changed
- Update and improvement of Polish translation from [@m-aciek](https://github.com/m-aciek).

## [1.0.0] - 2017-06-20
### Added
...

So I was thinking that maybe we can change the output to group by type of change and use a list to group the packages of the monorepo and just keep one command and have all packages already grouped in the unreleased section like it does the changelog of babel.

$ chan fixed 'Something on geut/cool-repo group' -g geut/cool-repo
$ chan added 'New thing on geut/cool-repo group' -g geut/cool-repo
$ chan added 'New second thing on geut/cool-repo group' -g geut/cool-repo
$ chan changed 'This brokes something on root base repo'

result into:

## [Unreleased]
### Added
- `geut/cool-repo`
  - New thing on geut/cool-repo group
  - New second thing on geut/cool-repo group

### Changed
- This brokes something on root base repo

### Fixed
- `geut/cool-repo`
  - Something on geut/cool-repo group

[Unreleased]

Added

• geut/cool-repo
  • New thing on geut/cool-repo group
  • New second thing on geut/cool-repo group

Changed

• This brokes something on root base repo

Fixed

• geut/cool-repo
  • Something on geut/cool-repo group

[dpaez]

Somehow I miss this point @estebanprimost, sorry about that. What @tinchoz49 is saying is right. Nevertheless, it is important to mention that keepachangelog does not make any mention to monorepos. So, at some point, we are working on a new feature.

Last but not least, for anyone else watching this issue, @elmasse made a mention that is worth to consider, here we are only talking about maintaining a root-level changelog file. This will match with the default Lerna config, for example. But if the user is on independent mode, the flow will change a bit and a changelog per package will be needed. My two cents.

[tinchoz49]

But if the user is on independent mode, the flow will change a bit and a changelog per package will be needed. My two cents.

I know that is not the best way but the current implementation allows us to define a path for changelog and something like: If your monorepo is:

root/
   geut/
     package1/
       CHANGELOG.md
     package2/
       CHANGELOG.md
   CHANGELOG.md

you can use something like:

$ chan fixed 'Something on geut/package1' -p geut/package1
$ chan added 'New thing on geut/package2' -p geut/package2
$ chan added 'New second thing on geut/package2' -p geut/package2
$ chan changed 'This brokes something on root base repo'

[dpaez]

But if the user is on independent mode, the flow will change a bit and a changelog per package will be needed. My two cents.

I know that is not the best way but the current implementation allows us to define a path for changelog and something like: If your monorepo is:

root/
   geut/
     package1/
       CHANGELOG.md
     package2/
       CHANGELOG.md
   CHANGELOG.md

you can use something like:

$ chan fixed 'Something on geut/package1' -p geut/package1
$ chan added 'New thing on geut/package2' -p geut/package2
$ chan added 'New second thing on geut/package2' -p geut/package2
$ chan changed 'This brokes something on root base repo'

Excellent suggestion @tinchoz49, the -p option will work like a charm. My only comment would be to not mix a root-level changelog with per-package changelogs.

[tinchoz49]

My only comment would be to not mix a root-level changelog with per-package changelogs.

Agree, the idea of keep-a-changelog is to create a readable changelog, something easy to understand and track what is happening in the project. Having multiple changelogs is not best way to acomplish that.

[estebanprimost]

@tinchoz49, @dpaez thanks for your comments!

So I was thinking that maybe we can change the output to group by type of change and use a list to group the packages of the monorepo and just keep one command and have all packages already grouped in the unreleased section like it does the changelog of babel.

This could be another way to order/group a changelog :+1: (not the primary idea behind this PR). Examples of different grouping strategy: material-ui, CRA and Babel.

Some of that examples contains releases with multiple versions of sub-packages, dunno if keepachangelog talks about that.

[estebanprimost]

After some discussion, I change grouping strategy (as @tinchoz49 suggest). Now it will be, some like:

## [Unreleased]

## 1.0.0 - 2017-06-20
### Added
- group-1
  - added 1

### Changed
- group-1
  - changed 1
- group-2
  - changed 2

### Deprecated
- Core
  - deprecated 1

### Fixed
- Core
  - fixed 1