Skip to content

Latest commit

 

History

History
22 lines (12 loc) · 1.3 KB

DEV.md

File metadata and controls

22 lines (12 loc) · 1.3 KB

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. Dont 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

Conventions

  • 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)[typelevel#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.

Release Process

Mouse uses Github Actions, https://github.com/djspiewak/sbt-github-actions and https://github.com/olafurpg/sbt-ci-release for CI releases. Use the Github Create Release feature to tag a release, and it will publish to Sonatype automatically (using @benhutchison credentials).

sbt-release is no longer in use.