New feature motivation

I've added semantic-release to some of my projects. Unfortunately, due to trial and error some of my pushes didn't get published. I can push a fix and thus publish a new release, but then the previous would-have-been release and its changelog seems to be lost. How would I recover or include the changelog of a failed release?

I had a look at the FAQ, but it only contai

Is it okay to include "rich" content like images, links to other projects, blockquotes, etc. in the changelog? While these things might make it more "enjoyable" to read, I can also see where they might make it harder for users to copy/paste and more complex for machines to parse. Whatever is considered the best practice with regards to rich content, I feel like that should be included in the FAQ.

Issue

In v7.1.0:

When you declare a custom file in bumpFiles standard-version will no longer update normal package.json, composer.json, lockfiles, etc. declared in the defaults.

This is fine (I don't think this is a bug because maybe you don't want it to bother with the defaults), but I think it should be mentioned in the documentation that when you do declare bumpFiles in your c

While inspecting the installer, I noticed the fallbacks for Linux / OSX when appdirs isn't available (in data_dir()).

Wouldn't it make sense to add an if for Windows based on %APPDATA% or %LOCALAPPDATA%, before resorting to globally installing appdirs?

We have a workflow where we want do generate the release notes only from pull requests and mention the pull request author. I have found no way to do this yet...

It took a few attempts to find a solution to get a version # to tag the releases with. In my case I have a VERSION file containing the version number, such as 0.1.0. This solution should be applicable even if the desired version is stored elsewhere so long as it can be accessed from a bash shell.

The first step gets the version via a run command and sets the output. See the [documentation for

@adamdubiel In the document, users should get the same output as the currentVersion task, but actually it is not. there is another issue #207 talks about this issue, but it has been closed.

In my scenario, I need the currentVersion output to update my grad

When creating a CHANGELOG, if the commit that increased the version number is not the most recent commit, two version headings can be created. Also, the commit that increased the version number is discarded. when creating an initial release it is probably common to update the package.json file with more than just the version number.

Version 0.1.0

• Update remaining files

Hi! I can't find any clear documentation about the asset_content_type field -- what the options are, what this does etc.

If there is some documentation in another place, maybe it'd be worth linking to it in the readme?

Sorry if there's been an existing issue for this -- I couldn't find any.

Got this message:

? Are you using GitHub Enterprise? No
ERR! semantic-release Error: GitHub repository URL is invalid: https:undefined.git

This was caused by the repo being SSH based, not HTTP(s). Took a while to figure this out, a clearer error message would make sense and make this easily fixable.

Code here:
https://github.com/semantic-release/cli/blob/d2b48b0ef70e327ae591a3

I've just stumbled upon conventional-github-releaser, having used standard-version for awhile and searching for a way to customize how the CHANGELOG.md is generated. It appears that the templating system may be provided by the underlying conventional-changelog tool, but I can't seem to find any documentation at any level of these tools which actually walks you through how to create a custom templ

commitizen allows you to specify a ticket number at the end of the process. This information is stripped from the changelog output.

How can I add it?

Situation

At the moment, this project uses and supports Python 2.7. As we all know, Python 2.7 is going out of maintenance soon ("retire") and it's not clear what the project is going to do.

After disussing #160, we found out that the project doesn't have a clear statement or information regarding the retirement of Python 2.7 (neither in issues, README, nor documentation). Maybe I have mi

I am not sure if this belongs here, but I am having an issue when using this Github Action.

This is the link to the github run that failed:
https://github.com/jampp/migratron/pull/25/checks?check_run_id=456554120

and the content is:

Uploading distributions to https://test.pypi.org/legacy/
Uploading migratron-1.1.0-py3-none-any.whl

  0%|          | 0.00/30.5k [00:00<?, ?B/s]
100%|