slaesvuo/hledger
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

;doc: contrib: commit messages: add more types

Browse Source
This commit is contained in:
Simon Michael 2021-07-05 13:16:15 -10:00
parent a4470c2a4d
commit e8cb743a23
1 changed files with 25 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
CONTRIBUTING.md
View File

@ -525,28 +525,40 @@ conventions for commit messages (WIP, will evolve as needed), aiming to
[Optional description, more details here when needed.] [Optional description, more details here when needed.]
``` ```
2. Every top-level commit must have a type prefix. This indicates the 2. Every top-level commit must have a type prefix, ending with a colon and optional space.
change's intended audience and the general type of change. This indicates the change's intended audience and the general type of change.
Here are the current types: Here are the current types:
- Changes visible to end users (including users of hledger-web's HTTP API). - **Changes visible to end users** (including users of hledger-web's HTTP API).
These will appear in release notes and changelogs: These will appear in release notes and changelogs:
- `feat` - a new feature - `feat` - a new feature
- `imp` - an improvement to existing features - `imp` - an improvement to existing features
- `fix` - a bugfix - `fix` - a bugfix
- Changes affecting packagers, builders (including users installing - **Changes affecting packagers, builders, and library users**.
from stackage or hackage), and library users (Haskell programmers These will appear in changelogs:
using our library APIs). These will appear in changelogs, but not in release notes:
- `cha` (or `pkg`, `lib` ?) - `cha` - a generic package/lib change. Or, one of these specific types:
- `pkg` - something to do with the haskell packages, dependencies etc.
- `lib` - a change in the package's library API
- ...some other type that seems useful...
- **Changes interesting only to hledger developers/documentors/debuggers**.
These will usually appear only in the commit history, not in changelogs or release notes:
- Changes of interest only to hledger developers/documentors/debuggers; - `dev` - a generic developer change. Or, one of these specific types:
these will be visible only in the commit history, not in changelogs or release notes: - `ref` - refactoring
- `cln` - cleanup
- `dev` (or `doc`, `ref`, `cln`, ... ?) - `doc` - documentation-related
- `test` - tests-related
- `ci` - continuous integration-related
- ...some other type that seems useful...
There's a bit of ambiguity/overlap between the cha/dev types and topics.
Eg the `doc` type indicates a boring doc change, but there's also a `doc` topic
which might be used for interesting doc changes, as in `feat:doc:...`. TBD.
3. If this is a "breaking change", introducing a compatibility or 3. If this is a "breaking change", introducing a compatibility or
migration issue, the type is followed by `!`, and the issue migration issue, the type is followed by `!`, and the issue
and advice to users are included in the description. and advice to users are included in the description.
@ -575,8 +587,8 @@ conventions for commit messages (WIP, will evolve as needed), aiming to
Crafting good commit messages (and thereby good commits, good change Crafting good commit messages (and thereby good commits, good change
documentation, easier code review, faster merging) is an art and a documentation, easier code review, faster merging) is an art and a
habit; we'll check and satisfy these conventions as part of CI and habit. Just use your best judgement and we'll check and polish
code review. as part of CI and code review. Examples will be added here in due course.
Related: Related: