Generate changelog from latest non-pre-release

[evanpurkhiser]

Hi, your automatic-releases action is great!

I use it to generate automatic master builds. However right now, because it builds every commit on master, the changelog is always just that one commit. I was curious if you had thought about adding an option to generate release notes starting from the most recent non-pre-release commit, or if you would be open to a PR implementing this.

[marvinpinto]

Hey @EvanPurkhiser! I think it should already do what you need, unless I've misunderstood something? By default releases from master generate pre-releases, in which case the changelog should only contain entries dating back to the previous pre-release.

If you generate regular semver releases (via a semver tag), it should include the changelog going back all the way to the previous semver tag. You can see an example of this on the release page here.

Is that what you were looking for, or something else?

[evanpurkhiser]

By default releases from master generate pre-releases, in which case the changelog should only contain entries dating back to the previous pre-release

If I create a pre-release from every master build, wouldn't that only ever be one commit listen in the change log? Since the pervious pre-release would have been the parent commit to the most recent master commit. My general perspective is that a rolling master pre-release build would always be X number of commits ahead of the most recent tagged release, which is what I would expect the pre-release description to include.

[marvinpinto]

Ahh, I think I understand what you mean now. To summarize:

You would like the (master) pre-release changelog to contain everything up until the previous (regular) semver release. Right now the (master) pre-release changelog only goes back to the previous (master) prelease.

Does that sound right @EvanPurkhiser?

I don't think I will have time to implement this in the near term and I'm open to a PR :+1:

(as with time commitments & life, I'll review/merge as and when I can)

[tangx]

Hey @EvanPurkhiser! I think it should already do what you need, unless I've misunderstood something? By default releases from master generate pre-releases, in which case the changelog should only contain entries dating back to the previous pre-release.

If you generate regular semver releases (via a semver tag), it should include the changelog going back all the way to the previous semver tag. You can see an example of this on the release page here.

Is that what you were looking for, or something else?

Thankyou, It's Helpful.

Changelog Commit Reflect Rules

https://github.com/marvinpinto/actions/blob/bb681da2f82883571023ffba1456c13737834bca/packages/automatic-releases/src/utils.ts#L38

enum ConventionalCommitTypes {
  feat = 'Features',
  fix = 'Bug Fixes',
  docs = 'Documentation',
  style = 'Styles',
  refactor = 'Code Refactoring',
  perf = 'Performance Improvements',
  test = 'Tests',
  build = 'Builds',
  ci = 'Continuous Integration',
  chore = 'Chores',
  revert = 'Reverts',
}

[asbjornu]

You would like the (master) pre-release changelog to contain everything up until the previous (regular) semver release.

I would prefer this behaviour as well.

[evanpurkhiser]

Yes that is correct @marvinpinto.

Sorry for this late reply, I've also been a little busy.

[ptr727]

Similar workflow, would also like changes between this and last release in branch, i.e. last release vs. last prerelease.

[maggie44]

+1 here too. Pre-releases would benefit from having all the commits listed in their changelog since the last semver release.

To highlight an issue with the current behaviour, when I publish a new pre-release over an existing one I lose all the previous commits from earlier pre-releases, which means users can't track changes during development, which makes the changelog for pre-releases a little futile.

Worth keeping in mind that if there is no previous tagged release, then it should include all commits. Could get a little messy at that length, but if it becomes out of control then users could use multiple pre-releases with progressive tags.

[guwirth]

Hi,

like to have same feature. #72 seems to be a solution. PR failed only because of lint issue. @marvinpinto maybe you can have a look to it?

Regards,