- Proposal: TE-0001
- Authors: Matthew Purdon
- Review Manager: TBD
- Status: Awaiting review
This proposal introduces the concept of "conventional commits" to the codebase. Conventional commits provide a standardized format for commit messages, allowing for clear and concise communication about code changes. This structure makes it easier to understand the history of a codebase and to automate release notes, versioning, and other processes that rely on the interpretation of commit messages.
Currently, our project lacks a unified and standardized approach to commit messages. This leads to inconsistency and difficulty in understanding the exact nature of code changes, tracking progress, and generating automated tools like changelogs. By adopting the "conventional commits" specification, we aim to resolve these problems, providing developers with a clear and effective method for communicating changes.
The proposal suggests the adoption of the "conventional commits" specification as described at Conventional Commits 1.0.0. Commit messages will adhere to a specific format that includes a type, an optional scope, and a description.
Examples:
feat(user-auth): add login functionalityfix(button): correct alignment issue
This structured format ensures clarity, consistency, and enables automation of various development tasks, such as semantic versioning and changelog generation.
Adopting conventional commits involves adhering to the defined specification without introducing new syntax or APIs. Developers must follow the prescribed format when committing code. Tools like linters or commit hooks can be used to enforce compliance.
The detail in this section can be found in the official specification, which outlines types, format, and guidelines for writing conventional commits.
This feature can be freely adopted and un-adopted in source code with no deployment constraints and without affecting source or ABI compatibility.
The adoption of conventional commits opens doors to further automation and standardization within the development workflow. Future possibilities include:
- Integration with automated release tools
- Enhanced collaboration with team members and contributors
- Extending the commit conventions to suit project-specific needs
One alternative would be to continue without standardized commit messages, relying on individual preferences and practices. However, this leads to inconsistency and challenges in collaboration, versioning, and documentation.
Another alternative would be to create a custom commit convention unique to our project. While this might cater to project-specific needs, it may lead to challenges in adoption and maintainability and lacks the widespread support and tooling available for conventional commits.
In summary, the adoption of conventional commits seems to be the most balanced and beneficial approach, offering clarity, consistency, and alignment with widely accepted best practices.