standard-version icon indicating copy to clipboard operation
standard-version copied to clipboard

Prerelease, release and changelog

Open noreiller opened this issue 7 years ago • 8 comments

Hi, I publish prereleases versions of my package and everything works fine, but once the release is ready, I would like to combine all the commits from the prereleases in the release changelog. Is there a way to do this ?

I tried the { skip: { changelog: true} } config for prereleases, but it doesn't help since the commits are releated to tags.

Thank you, Aurélien

noreiller avatar Aug 04 '17 12:08 noreiller

We're also having this issue. Ideally, it'd be great to be able to specify the type of version where we want the changelog to be generated from. I.e. generate the changelog from the last non prelease version.

yoitsro avatar Aug 04 '17 13:08 yoitsro

@yoitsro It's not so simple. I hijacked the library to be able to send { from: "v1.2.3" } in gitRawCommitsOpts but it's not working. The changelog successfully parses all the commit from the requested version to the last, but since, the library groups them by tag, it's not the result I would like.

One of the solution could be to avoid prerelease changelogs, this way, only release changelogs would be written. If the prerelease changelogs are mandatory, this could be another solution, but way more complex:

  • if the from tag is not the previous one
  • if prereleases tags are detected
  • if the last version is not a release
  • so the release could loop again on commits to list them in the release changelog.

noreiller avatar Aug 04 '17 13:08 noreiller

Hey @noreiller. So we're not actually generating the changelog on prereleases (in this case, our develop branch), but we do want the commit to be tagged with the prerelease version. This is because we want the package.json to be updated to reflect this version because it's the package.json version is read from within the app.

But then that means we need to actually push the tags (without any file changes) so that the next time our CI is run, it picks up on the last tag, changes the package.json version field, and then it can bump the version as per usual (with the prerelease version).

This is not ideal because on merges to master (where we do want the changelog generated, it can't see any differences between the last tag and the master branch because, technically, there are none.

Our desired behaviour would be for pushes to develop to do a prerelease bump (but not necessarily commit the file changes). Then, upon a push to master, to generate a changelog and version number from the commits which have been done since the last push to master. Any ideas?

yoitsro avatar Aug 04 '17 14:08 yoitsro

I was able to go around this by skipping the tag and changelog on prerelease, so on the next release it will generate the changelog based on the last actual release. yarn release --prerelease beta --skip.changelog=true --skip.tag=true

pmcalmeida avatar Feb 05 '18 18:02 pmcalmeida

This is really stale, however this is as far as I've taken it.

First off, I can't skip tags, as that is how my pre-release packages are triggered. I can probably fix this but I don't want to publish every feature branch and every commit. So tags are my event.

  1. prerelease with --skip.changelog
  2. push && ci publishes package.
  3. for a real release, I just delete that tag locally
    • not automated yet, but could be a pre-release to delete the tag
      • if the current version contains "beta"
      • get the tag name from (package.json:version)
      • git tag -d $ver

kinda meh.. not a fan of it, but maybe it'll help someone get around this.

ideally standard-version --pre-release --aggregate-pre-releases=true would be nice :)

brettswift avatar Dec 16 '20 17:12 brettswift

Realize today i never shared my workaround. So here it is:

We wanted:

type commit changelog tag  
release v1.2.3
prerelease 🚫 🚫 v1.2.3-rc.0

Desired: changelog generation relative to previous release, not last prerelease tag (e.g.; v1.2.3-rc.N)

So we just delete the non-release tags, run standard-version, and restore them

git tag -l | grep -vE '^v(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)$' | xargs git tag -d
npx standard-version [...args]
git fetch origin --tags

I would prefer this to be a feature of standard-version tho.

eckdanny avatar Jul 01 '21 17:07 eckdanny

Ideally, change logs should be generated in related to its tag (ie changes among pre release tags & changes among release tags).

alvis avatar Oct 01 '21 08:10 alvis

Is there any news about it ?

bencat-sixense avatar Feb 13 '24 14:02 bencat-sixense