On Sun, 2022-09-11 at 14:09 +0300, Hakan Bayındır wrote:
For versioning, I propose Semantic Versioning[0] (BiT might be already using this). [...] BiT’s versioning already fits this, and we can do things like 1.4.4beta1 to denote things are not pretty stable yet.
Semantic versioning is OK and as user I'd like to see also the release date in the version number to get a feeling how old the tool is that I am using. Could we add the release date to the CHANGE(LOG) file at least?
On the commit side, I find Conventional Commits[1] useful. It requires some mental adjustment, but it also forces good development practices by dividing big commits and limiting one fix per commit. This brings commit granularity, transparency and discipline. I apply it to my own projects, and I like it. [...] On the Changelog side, we can use a tool like Git Cliff[2], which creates changelogs from git commits automatically.
Excellent proposal, esp. together with Cliff BTW: I really love to learn best practices from others - that motivates me to contribute to project ;-)
Implementing these ways and adding such discipline may reduce our load in the long term, and make project more sustainable IMHO. We can codify this into a CONTRIBUTING.md file.
Good point, where can we add this TODO? We could also add the recommendation of "git rebase" or "merge --squash" to "compress" multiple (intermediate) commits into one feature/fix/... commit for a clean history that can be processes by Cliff...