Use of release-please and conventional commits

[aucampia]

I think we should try to stick to conventional commits, so we can automate releases and improve the release process. Currently, I'm updating the changelog by hand, and it is quite tedious and slow, and probably one of the reasons we release so infrequently.

I'm going to use https://github.com/googleapis/release-please then to make releases.

To get things working, I'm going to create a "shadow" fork of RDFLib and publish it under aucampia-rdflib-a on PyPI or possibly PyPI test to ensure everything is working as it should before switching the main repo over to this.

If anyone has objections or other suggestions, let me know.

CC: @ashleysommer @nicholascar @white-gecko @gjhiggins @edmondchuc

[edmondchuc]

Thanks for looking into this @aucampia, I think it's a great idea as it will improve and hopefully simplify the process of making new releases more frequently.

A quick question, does this mean PRs going forward will have their commits squashed and the commit message going into main will be in the conventional commits format?

[aucampia]

@edmondchuc squashing would be best because then maintainers can fix pull requests that have commit histories that are not compliant with conventional commits, though technically if each contributor used conventional commits, then other merge strategies would work also.

I have been trying to use conventional commits recently, squashing commits from contributors, but I sometimes forgot also. I will look if we can use merge-queues to do a final check on the commit history before it goes to the main branch.

[edmondchuc]

Sounds like a great use case for merge-queues. I've never used them before, will be keen to see how they are implemented here.

[aucampia]

@nicholascar I'm trying to adhere to conventional commits to this when merging pull requests, there is still some work to be done to streamline and document it, but already I can fairly easily use conventional-changelog to generate rather decent release notes from the main branch's commit history, see this for example, from main:

https://gist.github.com/aucampia/a2d4109f8d38307825295df23d6961d1 - there are some things in the output that are probably not ideal for the release note, maybe it can be filtered with the tool, but I don't know how yet, I just deleted some entries that weren't needed - like test changes, dependency updates and refactors - but deleting entries is much less of a burden than having to write the release notes from scratch.

Basically, what is needed is that when you merge you do a squash merge, and then in the message write the release note entry. Conventional changelog then uses each commit on main to create a release note entry. It is rather rudimentary as a tool, and the heavily lifting really comes from keeping the commit history of the main branch clean.

Using this approach, we can streamline releases even more, and ideally get to a point where we can do releases with just merging a pull request.