Versioning
Versioning is a way to name different versions of a software, allowing to keep track of the changes and updates over time.
A good naming convention is MAJOR.MINOR.PATCH.
MAJORversions have groundbreaking changes that often make it incompatible with previous version.MINORversions add features that are backward compatible with previous versions.PATCHversions often include bug fixes, also backward compatible.
Some point to keep in mind:
- Major versions start at 0, usually in a development/beta/unstable phase (e.g.
0.y.z)
Commit
When we send last changes to the repository through a commit, there is many way to write them. Here is a structural and standardised way to do it:
<type>(<optional scope>): <subject>Types
Here is typical example of types you can use to quickly target what the changes affect
build: build system and external dependencies (e.g. npm, pip, …)chore: related to environment and maintenanceci: CI/CD, configuration files and scripts, …docs: documentation related (e.g. README, …)feat: add new featurefix: resolve a bugperf: improve performancerefactor: improve structure/clean up the codebase without changing the logicrelease: push new version of the productrevert: switch back to change made in another commitstyle: cosmetic change (e.g. formatting, linting-related, …)test: add/improve test routines
Examples
build: add webpack config for productionchore(deps): update Node.js version in .nvmrcci(tests): add GitHub Actions workflow for testsdocs(api): update usage examples in READMEfeat(auth): add user login functionalityfix(auth): correct null pointer exception in middlewareperf(db): optimize database query for faster responserefactor(router): split monolithic file into smaller modulesrelease: version 1.2.0revert: undo changes from commit abc123style(lint): fix indentation in main.jstest(auth): add unit tests for login feature
Ressources
- semver.org – Article giving a good overview on semantic Versioning
- conventionalcommits.org – Guidelines to write