Community Announcements

Cats

Overview

Cats is a library which provides abstractions for functional programming in the Scala programming language. The name is a playful shortening of the word category.

Scala supports both object-oriented and functional programming, and this is reflected in the hybrid approach of the standard library. Cats strives to provide functional programming abstractions that are core, binary compatible, modular, approachable and efficient. A broader goal of Cats is to provide a foundation for an ecosystem of pure, typeful libraries to support functional programming in Scala applications.

Getting Started

Cats is currently available for Scala 2.10 (up to 1.2.x), 2.11, 2.12, 2.13.0-M4, and Scala.js.

Cats relies on improved type inference via the fix for SI-2712, which is not enabled by default. For Scala 2.11.9 or later you should add the following to your build.sbt:

scalacOptions +="-Ypartial-unification"

Or, if you need to support older versions of Scala you can use the sbt-partial-unification plugin which extends support back through Scala 2.10.6 or later, to add it, simply add this line to your plugins.sbt:

addSbtPlugin("org.lyranthe.sbt"%"partial-unification"%"1.1.2")

And then create the Cats dependency, by adding the following to your build.sbt:

libraryDependencies +="org.typelevel"%%"cats-core"%"1.6.0"

This will pull in the cats-core module. If you require some other functionality, you can pick-and-choose from amongst these modules (used in place of "cats-core"):

cats-macros: Macros used by Cats syntax (required).

cats-kernel: Small set of basic type classes (required).

cats-core: Most core type classes and functionality (required).

cats-laws: Laws for testing type class instances.

cats-free: Free structures such as the free monad, and supporting type classes.

Community

Gitter channel cats-dev is dedicated for Cats development related discussions. For people who wants to follow closely and/or to participate in the decisions in Cats development, this is the room to join.

People are expected to follow the Scala Code of Conduct when discussing Cats on the Github page, Gitter channel, or other venues.

We hope that our community will be respectful, helpful, and kind. If you find yourself embroiled in a situation that becomes heated, or that fails to live up to our expectations, you should disengage and contact one of the project maintainers in private. We hope to avoid letting minor aggressions and misunderstandings escalate into larger problems.

If you are being harassed, please contact one of us immediately so that we can support you.

Binary compatibility and versioning

After 1.0.0 release, we decided to use MAJOR.MINOR.PATCHSemantic Versioning 2.0.0 going forward, which is different from the EPOCH.MAJOR.MINOR scheme common among Java and Scala libraries (including the Scala lang).

Cats strives to provide a solid and stable foundation for an ecosystem of FP libraries. Thus, we treat backward binary compatibility maintenance with a high priority. In semantic versioning, backward breaking change is ONLY allowed between MAJOR versions. We will maintain backward binary compatibility between PATCH AND MINOR versions. For example, when we release Cats 1.1.0, it will be backward binary compatible with the previous 1.0.x versions. I.E. the new JAR will be a drop-in replacement for the old one. This is critical when your application has a diamond dependency on Cats - depending on two or more libraries that all depend on Cats. If one library upgrades to the new 1.1.0 Cats before the other one does, your application still runs thanks to this backward binary compatibility.

Also worth noting is that according to semantic versioning, MINOR version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated.

Any binary breaking changes will require a MAJOR version bump, which we will be very cautious about. We will also consider using organization and package name for major versioning in the future. But that decision is yet to be made.

We are currently following a practice of requiring at least two sign-offs to merge PRs (and for large or contentious issues we may wait for more). For typos or other small fixes to documentation we relax this to a single sign-off.