Absent `--change-log`, `-m` option behavior is wrong when change log could not be parsed

[sim642]

The man pages say:

       --change-log=FILE
           The change log to use. If absent, provided by the package
           description.

However if dune-release guesses some change log file to exist, but fails to parse it (dune-release: [ERROR] ./CHANGES: Could not parse change log.), then it completely gives up instead of using the documented default behavior of falling back to the package description.

If it cannot parse the change log it supposedly found, then it should pretend as if it didn't find one at all. The same goes for -m: it tries to very eagerly parse the change log and on failure doesn't do it's default:

       -m MSG, --message=MSG
           Commit message for the tag. If absent, the message 'Distribution
           VERSION' is used.

[NathanReb]

Thanks for reporting this. Could you give a bit more context so we can properly reproduce and fix this?

• Which version of dune-release are you running?
• Which dune-release command were you running?
• About the package you're trying to release, If it's public, could you give us the repo URL? If it's private, what's the project layout and changelog file content?

Falling back to the default behaviour upon parsing errors for changelog files indeed sounds sane. I'll take a look at this!

[sim642]

• Which version of dune-release are you running?

1.5.2

• Which dune-release command were you running?

I think it applies to most the steps: tag wants to read the changelog for the tag message, publish wants to read the changelog for the GitHub release description, opam submit wants to read the changelog for the PR description. So I had to manually provide -m to all of them.

• About the package you're trying to release, If it's public, could you give us the repo URL? If it's private, what's the project layout and changelog file content?

https://github.com/goblint/cil. Basically the culprit there is the decades old CHANGES (no extension) file, which is neither Markdown nor Asciidoc, but just some random plaintext. Of course I could try to convert that into dune-release-acceptable changelog format with some sed-fu, but I don't care enough about it. It's otherwise easy enough to just manually specify the git tag with the desired version and not have meaningful changelog text in the tag/release/PR (and let it be the default), but the changelog parse attempt ruins this convenience.

[NathanReb]

The tag step will always need a changelog it can parse because its only purpose is to create a tag from the latest changelog entry.

You can simply tag the repo yourself with the version you want to use and proceed with the release.

If you're interested in using the default changelog format you could also start by using the expected changelog format for new release and keep the old entries the way they are. From the look of your changelog it should work. Something along those lines would do:

## 1.8.3

...

## previous versions

18 November 2021: goblint-cil-1.8.2

    * Add columns to locations.
    * Add support for __int128, __int128_t and __uint128_t.

18 May 2021: goblint-cil-1.8.0

...

That being said, dune-release should still use good defaults when the changelog can't be parsed.

[gridbugs]

Would it be worth updating the docs for the --change-log argument to include the expected format of the changelog file, or have the error message explain why the changelog file failed to parse?