Use release-please to release libthumbor

[guilhermef]

I've been using release-please to release thumbor-plugins.
It automatically creates the release and changelog based on the commits since the last release.

It also automatically bumps the version based on https://www.conventionalcommits.org/en/v1.0.0/#summary

Example: thumbor/thumbor-plugins#68

@scorphus @heynemann @marcelometal What do you think?

[heynemann]

The problem for me is that in thumbor-plugins you have 23 releases when in truth there were only a few actual releases (0.1.2). It is misleading for users of the package. Maybe there's a way to distinguish between nightlies and actual releases.

…

On Thu, Mar 31, 2022 at 5:45 PM Guilherme Souza ***@***.***> wrote: I've been using release-please to release thumbor-plugins. It automatically creates the release and changelog based on the commits since the last release. It also automatically bumps the version based on https://www.conventionalcommits.org/en/v1.0.0/#summary Example: thumbor/thumbor-plugins#68 <thumbor/thumbor-plugins#68> @scorphus <https://github.com/scorphus> @heynemann <https://github.com/heynemann> @marcelometal <https://github.com/marcelometal> What do you think? — Reply to this email directly, view it on GitHub <#50>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAO4JJJIXMRPNPVLFRAF3DVCYFFVANCNFSM5SGT6LZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[guilhermef]

I agree with you, this was a mistake on my side during testing.
Ideally, I should have started the commit messages with chore: this would have informed release-please that the change was not releasable.

The idea behind this proposal is to have a release process tracked via a PR.
When a releasable unit is committed, it would create a new PR to track the changes and it would be finally released when the PR is merged.

https://github.com/googleapis/release-please

This way we would avoid us having to generate and upload the package locally.