1.0

[larsrh]

What is missing for a 1.0 release?

@johnynek argued that we should give bincompat guarantees, so I figure it's time for a 1.0 series.

[armanbilge]

Before 1.0, we should switch the algebra dependencies to the forthcoming cats-algebra.

[armanbilge]

I'd be happy to help 1.0 to materialize. In preparation for this, I think at least a couple of the PRs are 90% baked so can be finished up, and certainly a few of the open issues can be addressed. How long is the goal to continue publishing for Scala 2.12, can it be dropped for 1.0?

[johnynek]

I chimed in on the cats-algebra thread. I'm very -1 on renaming the packages. And you can see a good example here.

Now we are saying, let's also break compatibility in cats-collections just so we can change the package name. I'm -1.

I think we should keep compatibility in algebra as we move the code into cats, and we should publish 1.0 here as is without blocking on that release since it will be compatible (especially for all the trait definitions).

[gemelen]

For ease of reference: typelevel/cats#3918

[armanbilge]

@gemelen FYI We moved algebra into cats binary-compatibly (this was the right thing to do) so there is no need for any changes here.

[gemelen]

Yep, I found out that it's a part of the cats now, but thanks for the info anyway.

[armanbilge]

@gemelen I think it would be fantastic to start working seriously towards 1.0. I think two very good first steps toward this would be:

• Fix the warnings and enable fatal warnings in CI #486
• 0.9.4 as intermediate release #456

Then we can start triaging for 1.0. I'm happy to help review PRs where I can, please @ me.

[armanbilge]

Nice job releasing v0.9.4 🎉

Next step towards 1.0: does anyone have time to work on #486? :) It's not strictly necessary per-se, but IMHO fatal warnings enabled shows a commitment to code quality.

[armanbilge]

Another update on this: I am becoming increasingly convinced of the importance of releasing a Cats Collections 1.0 to support several projects across the Typelevel ecosystem.

1. idna4s has recently adopted the Cats Collections' BitSet. That lib will be used in ip4s and cats-uri, which themselves are dependencies of FS2 and http4s.
2. There is a proposal to make CIString in case-insensitive 2.x an opaque type. There is also a proposal to use a Map[CIString, Chain[String]] for the Headers datatype in http4s 1.x. These optimizations will only work together if we use the typeclass-based HashMap recently introduced to Cats Collections.
3. The cats-effect-std module currently has internal private implementations of several data structures already in Cats Collections. It would also benefit from the new HashMap for its MapRef type. Once Cats Collections is stable, it should take it on as a dependency.

It's unacceptable for these projects to take on Cats Collections as a dependency until it guarantees stability.

All this to say: it would be fantastic if a volunteer can champion Cats Collections 1.0 across the finish line. I am stretched too thin but can play a supporting role.

I think there's several "cleanups" that could be done, at the cost of breaking binary-compatibility between 0.9 and 1.0. For example #315 and removing the "Haskell cargo-cult" of requiring constraints on methods (see typelevel/cats#4147 (comment)).

@johnynek do you have any thoughts on that? In #277 (comment) you argued against breaking binary-compatibility, in which case we might as well release 1.0 today?

[gemelen]

I could not not respond here, at least to set the expectations about my level of involvement: unfortunately, I live in Ukraine and I'm a bit distracted by the war to be able to put more than it's required to keep this library afloat. That's said, I'd still try to help with what's need to be done from my side.

[johnynek]

Sorry I missed the question earlier.

I think that cats-collections hasn't yet achieved its potential for adoption. If we think that breaking binary compatibility now could help that and remedy some design issues, I can see the value in it.

I think since we do seem to have inconsistent takes on internal vs external representation of associated type classes (Order and Hash required for some collections), that was maybe a mistake we should fix.

I still believe that in a language like scala where typeclasses are first class values and we don't have coherence, it doesn't make since to consume required typeclasses at callsites if using the wrong one invalidates the datastructure (which it does for hashmaps and trees with Hash and Order respectively).