When should we consider a proposed library "good enough"?

[jvican]

@nafg

I think another takeaway is, instead of having proposals like “add library X to SPP” (usually by its author), we should have a proposal “add functionality X to SPP, but we have to choose between libraries A, B, and C.” T

This is in fact how it works. For the Committee to review a proposal, first someone has to propose a library to solve functionality X with a library Y. This proposal is the one that takes precedence. Then the Committee takes this proposal and identifies the problem at hand, analyze whether it’s one the Platform should provide a solution for, find other alternatives and assess them all based on the aforementioned module criteria.

However, this process requires someone to show interest into adding X into the Platform – otherwise the Community would not actively propose the inclusion of libraries but rather wait on the Committee to decide which use cases are worth submitting a proposal for. And I think this would be the wrong approach.

@pathikrit

There is another way besides evolving i.e. building on top. In this case, instead of “evolving” better-files, keep it as is and acknowledge that its just a nice way to use Java NIO. Basically abstract away “pain to deal with Java” into better-files and have a TBD library deal with providing pure monadic interfaces built on top of better-files?

I also agree this is the way to go .

@jducoeur

Essentially, the Platform project is about picking winners. I’m enough of an armchair economist to be intrinsically a little suspicious of that, and the library world evolves fast enough that I suspect we are going to need some flexibility to adjust to the times.

The flexibility is provided by the compatibility guarantees. They allow us to remove a library and replace it in every major release of the Scala Platform, which was set to 18 months but we discussed that it would be reasonable to use instead 12.

Things are dynamic and change over time. Software is not an exception. Stability is a great concern but, at the same time, I get your point that we should react to the development of other better alternatives developed later to the acceptance of a module.

However, we should encourage that changes are done in the Platform modules (i.e. Platform modules are evolved) rather than outsourcing its development into external repositories whose changes are not to be merged back. This is possible when changes are not over intrusive – which happens most of the time in stable libraries, to be honest. I would argue that comparing scala-js-react with an IO library is not fair, the first one requires a research component that is not inherent to the IO domain. IO libraries have been for a long time in our hard drives, but react libraries have not.

I think we should be prepared for the situation that @jducoeur depicts to happen. In that case, I suggest that we carry out the deprecation cycle that we’ve been talking about (+ potential automatic migration). But it’s important to note that most of changes can be worked out by all the Scala developers in the same module. And it’s important that modules are actively maintained because both our personal code and companies’ code will depend on it. We should join forces if possible.