Design Process for Adding a Feature
Check the feature isn't already available or readily achievable with existing operations
Consider and minimize risk of naming collisions for users who have imported mouse into existing code scopes. Don't use overly short or generic names if possible.
Add a test and test the feature manually. Use the simplest test code that covers the added behavior - simple features do not need complex tests.
Mention in the example section and in the release notes in README.md
- When an operation is provided in two variants that do the same thing, but differ in whether the arguments are evaluated lazily ("by-name") or eagerly, we have used the suffix
L(for Lazy) to distinguish the names (see #247) for example).
However, for new operations, simply providing a lazy by-name variant is often the best choice unless there are clear reasons (eg performance impact) for needing an eager variant.
Mouse uses Github Actions, sbt-github-actions and sbt-typelevel for CI releases. Use the Github Create Release feature to tag a release, and it will publish to Sonatype automatically (using @benhutchison credentials).
Choosing an Appropriate Base Branch
There are two options for choosing a base branch for your PRs:
mainbranch if you would like to deliver changes within the
1.xseries. It's for binary-compatible changes only.
series/2.xbranch if you would like to deliver changes within the
2.xseries. It's for non-binary-compatible changes and basically stands for the next major