diff --git a/.copier-answers.yml b/.copier-answers.yml index 70e3389d..365b51e0 100644 --- a/.copier-answers.yml +++ b/.copier-answers.yml @@ -2,7 +2,7 @@ # Answer file maintained by Copier for: https://github.com/KyleKing/calcipy_template # DO NOT MODIFY THIS FILE. Edit by re-running copier and changing responses to the questions # Check into version control. -_commit: 1.9.6 +_commit: 1.9.7 _src_path: gh:KyleKing/calcipy_template author_email: dev.act.kyle@gmail.com author_name: Kyle King diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 277c87d1..1df30ebf 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -49,7 +49,7 @@ repos: rev: 0.7.17 hooks: - id: mdformat - additional_dependencies: ["mdformat-mkdocs[recommended]>=1.0.6"] + additional_dependencies: ["mdformat-mkdocs[recommended]>=1.1.1"] args: [--wrap=no] exclude: _.+\.md|CHANGELOG\.md|CODE_TAG_SUMMARY\.md - repo: https://github.com/shellcheck-py/shellcheck-py diff --git a/docs/docs/STYLE_GUIDE.md b/docs/docs/STYLE_GUIDE.md index 9bf7462e..4a12a7bb 100644 --- a/docs/docs/STYLE_GUIDE.md +++ b/docs/docs/STYLE_GUIDE.md @@ -9,51 +9,51 @@ We use [Commitizen](https://github.com/commitizen-tools/commitizen) to manage bo > `type(scope): description` - **Types** - - *fix*: A bug fix - - *feat*: A new feature - - *docs*: Documentation-only changes (code comments, separate docs) - - *style*: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons) - - *perf*: A code change that improves performance - - *refactor*: A change to production code that is not a *fix*, *feat*, or *perf* - - *test*: Adding missing or correcting existing tests - - *build*: Changes that affect the build system or external dependencies - - *ci*: Changes to our CI configuration files and scripts - - A `!` can be used to indicate a breaking change (`refactor!: drop support for Node 6`) - - **SemVer Rules** - - Based on commit type, the version will be auto-incremented: `fix : PATCH // feat : MINOR // BREAKING CHANGE : MAJOR` + - *fix*: A bug fix + - *feat*: A new feature + - *docs*: Documentation-only changes (code comments, separate docs) + - *style*: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons) + - *perf*: A code change that improves performance + - *refactor*: A change to production code that is not a *fix*, *feat*, or *perf* + - *test*: Adding missing or correcting existing tests + - *build*: Changes that affect the build system or external dependencies + - *ci*: Changes to our CI configuration files and scripts + - A `!` can be used to indicate a breaking change (`refactor!: drop support for Node 6`) + - **SemVer Rules** + - Based on commit type, the version will be auto-incremented: `fix : PATCH // feat : MINOR // BREAKING CHANGE : MAJOR` - **Scopes** - - A Class, File name, Issue Number, other appropriate noun. As examples: `build(poetry): bump requests to v3` or `style(#32): add missing type annotations` + - A Class, File name, Issue Number, other appropriate noun. As examples: `build(poetry): bump requests to v3` or `style(#32): add missing type annotations` - **Tips** - - What if a commit fits multiple types? - - Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is the focus on more organized and intentional changes - - Use `git rebase -i` to fix commit names prior to merging if incorrect types/scopes are used + - What if a commit fits multiple types? + - Go back and make multiple commits whenever possible. Part of the benefit of Conventional Commits is the focus on more organized and intentional changes + - Use `git rebase -i` to fix commit names prior to merging if incorrect types/scopes are used ### Git Description Guidelines - [Commit message guidelines](https://writingfordevelopers.substack.com/p/how-to-write-a-commit-message) - - Full sentence with verb (*lowercase*) and concise description. Below are modified examples for Conventional Commits - - `fix(roles): bug in admin role permissions` - - `feat(ui): implement new button design` - - `build(pip): upgrade package to remove vulnerabilities` - - `refactor: file structure to improve code readability` - - `perf(cli): rewrite methods` - - `feat(api): endpoints to implement new customer dashboard` + - Full sentence with verb (*lowercase*) and concise description. Below are modified examples for Conventional Commits + - `fix(roles): bug in admin role permissions` + - `feat(ui): implement new button design` + - `build(pip): upgrade package to remove vulnerabilities` + - `refactor: file structure to improve code readability` + - `perf(cli): rewrite methods` + - `feat(api): endpoints to implement new customer dashboard` - [How to write a good commit message](https://chris.beams.io/posts/git-commit/) - - A diff will tell you what changed, but only the commit message can properly tell you why. - - Keep in mind: [This](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) [has](https://www.git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) [all](https://github.com/torvalds/subsurface-for-dirk/blob/master/README.md#contributing) [been](http://who-t.blogspot.co.at/2009/12/on-commit-messages.html) [said](https://github.com/erlang/otp/wiki/writing-good-commit-messages) [before](https://github.com/spring-projects/spring-framework/blob/30bce7/CONTRIBUTING.md#format-commit-messages). - - From the seven rules of a great Git commit message: - - 2. [Try for 50 characters, but consider 72 the hard limit](https://chris.beams.io/posts/git-commit/#limit-50) - - 7. [Use the body to explain what and why vs. how](https://chris.beams.io/posts/git-commit/#why-not-how) + - A diff will tell you what changed, but only the commit message can properly tell you why. + - Keep in mind: [This](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) [has](https://www.git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) [all](https://github.com/torvalds/subsurface-for-dirk/blob/master/README.md#contributing) [been](http://who-t.blogspot.co.at/2009/12/on-commit-messages.html) [said](https://github.com/erlang/otp/wiki/writing-good-commit-messages) [before](https://github.com/spring-projects/spring-framework/blob/30bce7/CONTRIBUTING.md#format-commit-messages). + - From the seven rules of a great Git commit message: + - (2) [Try for 50 characters, but consider 72 the hard limit](https://chris.beams.io/posts/git-commit/#limit-50) + - (7) [Use the body to explain what and why vs. how](https://chris.beams.io/posts/git-commit/#why-not-how) ### Issue Labels and Milestones Personal Guide -- For Issue Labels, see [labels.yml][labels] +- For Issue Labels, see \[labels.yml\]\[labels\] - Milestones - - **Current Tasks**: main milestone (*name could change based on a specific project, sprint, or month*) - - **Next Tasks** - - **Blue Sky** + - **Current Tasks**: main milestone (*name could change based on a specific project, sprint, or month*) + - **Next Tasks** + - **Blue Sky**
Research @@ -127,25 +127,25 @@ Personal Guide -- [Git: The Simple Guide][simple_git] -- [Commit Messages][gcmsg] and [why use the present tense](https://news.ycombinator.com/item?id=8874177) +- \[Git: The Simple Guide\]\[simple_git\] +- \[Commit Messages\]\[gcmsg\] and [why use the present tense](https://news.ycombinator.com/item?id=8874177) - [GitHub's Advice on GitHub](https://github.com/erlang/otp/wiki/Writing-good-commit-messages) - [Most Comprehensive Guide](https://chris.beams.io/posts/git-commit/) - [Git Pro Book (free)](https://git-scm.com/book/en/v2) - - [Bash Tab-Completion Snippet](https://git-scm.com/book/en/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Bash) + - [Bash Tab-Completion Snippet](https://git-scm.com/book/en/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Bash) ## Python - Python Style Guides - - - - - - - - - - - - - - + - + - + - + - + - + - + - ## ADRs