Use semantic-release

[xmnlab]

@fccoelho I was reading the PR template and it reminded me about semantic-release.

I have played with https://semantic-release.gitbook.io/semantic-release/ and it looks very interesting. Also, it is now used by ibis-project as well.

Initially, it looks a bit weird, because we are used to creating a tag for a bunch of changes (bugfixes+enhancements+support+documentations+etc), but semantic-release creates a tag for every new enhancement or for every new bug fix or for every new breaking change commit. Considering the idea of the version pattern commonly used, MAJOR.MINOR.PATCH, it makes total sense to have a tag for every case I mentioned before.

when a commit goes to main, according to the initials, semantic-release recognizes if it is a new feature, a bug fix, or a breaking change and creates a github tag and also the changelog file based on the commit message/PR title. so, we could do it instead of just asking to the PR author to select the PR type in the first comment.

it seems that semantic-release can be extended with plugins to do more actions. To implement semantic-release, basically, we need to add 2 files to the repo: a github actions (or at least a github step into an existent workflow) and a .releaserc.json file with the configuration for semantic-release.

We also could add a github template for PRs that would explain the commit message stuff.

I think that it is a very simple and straightforward approach.

I have here a Proof of Concept: https://github.com/osl-incubator/poc-semantic-release and here I have the necessary files:

https://github.com/osl-incubator/poc-semantic-release/blob/main/.releaserc.json https://github.com/osl-incubator/poc-semantic-release/blob/main/.github/workflows/release.yaml#L41

probably it would be a low priority, but I would like to share this thought here :)

[fccoelho]

Looks like a good Idea, because I was thinking about opening an issue for standardization of Issue naming. But like you said its not one of our top priorities. If we can find a way to easily teach this to our analysts, we can gradually introduce it!

[xmnlab]

nice! I had a talk last week about a common git workflow used by open source projects (maybe big projects). So, we covered:

• github fork
• github remotes (origin and upstream)
• git squash and merge strategy
• squash commits locally using git rebase -i
• resolving git conflicts

maybe for semantic release, we could just update the PR template with the information about the PR title, and maybe we could have a quick meeting to explain about that.

thoughts?