zestsoftware / zest.releaser

Python software releasing made easy and repeatable
https://zestreleaser.readthedocs.io
GNU General Public License v2.0
198 stars 62 forks source link

Can addchangelogentry only add a commit message if there's only nothing_changed_yet line? #330

Closed idgserpro closed 5 years ago

idgserpro commented 5 years ago

We're using zest.releaser in a buildout installation and thought about the following requirement: when using addchangelogentry --no-input "My message", the message would be added if the only message in that release is nothing_changed_yet: otherwhise, no changelog entry is added.

Is this a viable implementation in zest.releaser with a flag or something, or should be done in a plugin?

mauritsvanrees commented 5 years ago

To me, this seems a strange thing to want. Well, maybe you are thinking of a message like "No changes since last release", or "Finalized release", which may be a fine message when a release candidate was previously made, and now you only want to add such a message if you create a final release and there have been no changes since the release candidate. So it is basically a rerelease of the same code with a different version number. Is that what you are thinking of?

It might be doable in zest.releaser, but you could also hack that in bash with something like this, checking if the lasttaglog command from zest.releaser gives more than 9 lines:

if test $(lasttaglog | wc -l) -gt 9; then
    echo "there were some actual changes"
else
    addchangelogentry "Finalize release."
fi
idgserpro commented 5 years ago

Is the magic number 9 test to check if the last commit was the zest.releaser default message?

INFO: Showing log since tag 1.0.3 and the last commit.
git log 1.0.3..HEAD
commit c847bde387cc0d31899d3f94a1fe34272b4b84e
Author: Author <author@domain>
Date:   Wed Jul 31 16:34:50 2019 -0300

    Back to development: 1.0.4

    [skip ci]
mauritsvanrees commented 5 years ago

Yes. Or rather to check if there was only one commit since the last release, which we then assume to be the default message. You could use a slightly larger number, in case git returns more information in a future version.