jcornaz / autorel Goto Github PK

If a hooks contain the ' character, it may at best print an incorrect message in the console, and at worse fail.

At the moment the shell context is not preserved between the different command lines. That may surprise the user.

Example:

hooks:
  verify:
    - mkdir test # Create test directory
    - cd test # Enter test directory
    - echo $PWD # We are NOT in the test directory. Because each line has a new shell context

There is no need to share a same context between different phases (verify, prepare and publish). But inside a given phase, all commands should be invoked in the same context.

It should be impossible to have a release being published without the tag and commits being published too.

See: conventional-commits-rs/conventional-commits-parser#13

For rustaceans, it should be possible to install the CLI with:

cargo install autorel.

If a commit has multiple breaking change footers, only the last one appears in the changelog. But they should all be appear.

I'd like to have a "performance" and a "deprecated" sections in my changelog.

I'd be nice if I could define custom changelog sections with their respective commit type.

Not finding a previous versions in the tags is very likely to be the symptom of a missonfiguration.

Maybe the user forgot to fetch the tags when cloning, or forgot to define the appropriate tag prefix in the config file.

In any case, it would be better abort (by default) if no previous version is found.

For the first release, one could explicitly append a --force flag to proceed with the release, even if no previous version is found.

Search and replace strings when releasing is a quite common operation.

Right now I have to:

1. Use sed in the prepare phase
2. Explicitly add the concerned file in the list of files to commit

It'd be nice if I had only a simple and single config step. Maybe something like:

search_and_replace:
    - file: README.md
    - search: "version = \".*\""
    - replace: "version = \"{{version}}\""

And that search-n-replace step would take care of updating the file as well as commiting it.

Even if there is nothing to release

If last version is 0.3.4, then calling autorel --stable should release the version 1.0.0. Even if there is no changes since version 0.3.4.

Sometime we may make breaking changes that are a preparation for an incoming feature.

After that kind of change, the main branch is perfectly releasable, but contains only breaking changes and no feature. That means users of the software/library being released get the annoyance of the breaking change without the value of a feature/fix.

That situation is pretty easy to detect and avoid. A release should happen only if there are new features and/or fixes. If there are only breaking changes, it shouldn't be released.

Probably the (existing) --force flag should cause the force the release to happen, even if when there are only braking changes.

Allow to only print/update the changelog (without the rest of the release process).

It should probably be a sub command that can have specific options like --from and --to.