pre-release improvements

[bcoe]

The work done in #129 by @e-cloud on pre-releases is awesome; I think things are 99% of the way there, and this will be a great feature.

I don't think the CHANGELOG generation is quite there yet though.

Current Behavior

Currently, if I release a pre-release, decide it's awesome, an then promote it to the actual release; it will result in a CHANGELOG that the entry 1.0.0-pre with a description of all the changes, and 1.0.0 with no changes whatsoever, because the changes fall under 1.0.0-pre.

Ideal Behavior

Until the next actual release takes place, I think it would make sense to group all changes under an Upcoming header, we would then replace upcoming with whatever the next non-pre-release version is.

Is this the right behavior? other ideas? CC: @Tapppi, @e-cloud, @stevemao

[Tapppi]

I think a side effect of the workflow/ideal behavior is that the changelog might include invalid information regarding a feature that has then been altered by a later feature.

E.g. the changelog might include a feat: add customName option that later before a release is done is removed because it is entailed by feat: add metadata option. It'll be confusing to read about a new feature that actually doesn't exist anymore in the same form.

I can't come up with any easy way to solve this, other than allowing an option (--preview?) to edit the changelog before the commit of it..

This sounds like a separate issue, except when doing pre releases, changes like this are more common for a particular release than with no pre releases (the change will probably come in a later version then). When they are grouped by pre release, they are at least ordered...

[bcoe]

@Tapppi put some thoughts here: #152

[stevemao]

Maybe we could duplicate some entries. EG:
We put a complete log from v1.0.0 to v2.0.0 before any v2.0.0-pre sections, but keep all v2.0.0-pre sections as is?

[stevemao]

Also wanna share something from http://keepachangelog.com/en/0.3.0/, and I followed the part "Unreleased" when I was working on conventional-changelog. The difference is that they don't use pre release but unreleased so this might be off topic...

We have an outputUnreleased option. But don't have a way to remove unreleased section once there's an actual release. I don't want to include any read file features to conventional-changelog-core as it's just a tool to output a CHANGELOG (and doesn't even have to be a text file). BUT we can use releaseCount = 0 to always re-write the whole CHANGELOG. (I should add this to the docs (conventional-changelog/conventional-changelog#196))

[dherges]

Idea: should the prerelease name be added to the publishConfig in package.json?

Say: standard-version --prerelease alpha

package.json:

   /* .. */
  "publishConfig": {
    "tag": "alpha"
  },
 /* .. */