There have been micro-discussions of this issue here and there, so feel free to add pointers or just copy/paste. The point isn’t to start over, just to bring the discussion into focus.
I think there has been a bit of sidestepping the issue of how the platform is intended to be used, and it’s certainly reasonable to kick details into the future, but I think at least a general statement of intended usage is important. If you don’t know what you’re delivering it’s very easy to get off track.
So I will offer a possible starting point that seems reasonable to me. Here’s the lowball version:
- Platform modules have a GitHub badge and
scala-platform
metadata tag on Scaladex, and possibly a landing page like typelevel.org but are otherwise no different from any other libraries from the end-user’s point of view.
This has the benefit of being very simple but leaves version hell as the end-user’s problem. In the general case you want the flexibility to pick and choose but for beginners it’s a lot to bite off.
So a higher-end solution might also include:
- An sbt plugin that provides a way to load up a given platform release, with settings that you can include for each module, with known compatible versions of everything, like Typelevel’s sbt-catalysts.
With the “big-step” development process being suggested in the proposed process something like this seems reasonable.
The discussion of white-listing and transitive closure for the platform hints at additional tooling that could be useful, such a provided ScalaStyle config that provides warnings for imports outside of the platform (for those who intend to be strict about it) or even IDE plugins that can warn when your code has traversed off of a platform API into a white-listed dependency that’s not explicitly supported. This kind of thing seems fine to put off until later but I think it’s useful to think about what the ideal user experience would look like.