how to proceed as a module author after a trial release

The problem occurs to me using Perl5 for programming and Dist::Zilla (dzil) for deploying to CPAN. But the question is probably a general one, meaning independent of the programming language.

Problem description

Assuming I'm releasing a new version 0.1 of the module Foo with a new feature called bar. I would like to release it as a trial release (dzil build --trial), to be able the get feedback on the change without forcing it onto unaware users. When I'm doing so using my toolchain, the Changes file will look something like this:

1 Revision history for Foo
2
3 0.1       2019-06-19 17:49:09+02:00 Continent/City (TRIAL RELEASE)
4  - added bar

The packed distribution (for upload to CPAN) is a file like so: Foo-0.1-TRIAL.tar.gz

Until here, everything was easy. But from now on, I'm unsure how to react to upcoming events:

Feedback is positive. No changes needed. Bring the release in production.

How should the new (but unaltered) release look like? Should I do a release with the same version or count the version up? Should I add a new line to the Changes file (e.g "bring trial 0.1 into production") or alter the existing one (meaning just removing the (TRIAL RELEASE)).

Feedback is negative. Changes needed. Add feature/change baz.

Same questions here. The new change surely needs a mention in Changes. But again: Count version up, or let it be? Make a new entry to Changes or alter the existing one?

This is one of these questions where I feel like: it probably doesn't matter to much, but there must be a "best practice". And in the long term it kind of pays of doing it right.

Question

How should I continue with version numbering and Changes file, after doing a trial release to specifically CPAN?

(General answers, which are independent from Perl and CPAN are also of interest)

Solution

My general advice is: if the TRIAL turns out to be a resounding success and there are zero changes aside from releasing the same thing without --trial, you can reuse the version, since at runtime the two tarballs will have identical behavior. If you have to make any changes that may affect users or tests, bump the version. If you're unsure, bump the version -- versions are free. Remember that without a distinct version, other distributions can't distinguish the changes in their dependencies, CPAN clients can't request a specific version easily, etc.

As far as the changelog, it may help that MetaCPAN now includes the changes for any trial releases leading up to the stable release in its changes preview, provided it can parse your changelog and the trial releases are marked as such. (example) So I would just include an entry for each distinct version.