larsrh on gh-pages
updated site (compare)
larsrh on gh-pages
updated site (compare)
larsrh on revert-216-docs
larsrh on master
Revert "fix homepage (#216)" T… Merge pull request #220 from ty… (compare)
larsrh on v1.0.1
larsrh on master
Setting version to 1.0.1 Setting version to 1.0.2-SNAPSH… (compare)
larsrh on gh-pages
updated site (compare)
johnynek on master
build for 2.13.0-M5 (#223) * b… (compare)
discipline
, the dependency on scalacheck
and the laws encoding a lot of structure.
I'll create a ticket, capture the discussion from here. A couple of comments:
Is there a problem of duplicating the
cats-core
syntax code in algebra?
Its code duplication. We'd end up with 2 copies of the same code to solve the same problems. Over time they can diverge, leading to slightly different syntax depending where you imported from.
To me its a fallback option. I'd prefer to try tackle the root problem and migrate the cats-kernel syntax into kernel where it belongs. only if thats intractable then resort to code duplication.
Otherwise we need source and binary compatibility from machinist as well.
Machinist is a bit special though, its macro generators rather than another library. I think its pretty stable, unlikely to be an problem...?
every release of cats breaks binary compatibility.
Are you referring to kernel, or cats core?
Cats-core is pre 1.0. My read of the consensus feeling from the community is that binary compat pre-1.0 is less important than "getting it right". After 1.0 the pace of change will slow - thats the stated plan IIUC..
As a maintainer of big codebases you probably feel the impact more than most. But if you're building atop pre-1.0 software you signed up to that to some degree..?
cats-kernel
, the pace of change will be glacial: there is a commitment to preserve binary compatibility across minor releases.