For general, I can’t say but for this particular case there isn’t a seperate release. Rather the current release is the draft proposal and then assuming the SLIP is approved, for this case it may just be a matter of removing the milestone from the version and releasing that way, or it could be more complex than that (I am not sure what the publishing requirements for the SP are).
At least personally I don’t want to maintain a seperate release for the SP, and that is against the design goals of the SLIP in the first place.
It probably doesn’t help that we don’t have any guiding examples of Scala Platform libraries, but from what I understand from this proposal is that it is much anticipated and expected to gain high adoption. The only thing stopping it from gaining high adoption is it not having a stable release, and the only thing stopping it from having a stable release is it not being accepted in the platform (yet).
But you indicate there won’t be a separate platform release.
So what I don’t get is how being part of the platform is going to help producing one, if a stable release is a requirement for being part of the platform - in other words, what a stable release as a platform library is going to accomplish over a stable release as a non-platform library.
Library authors have explicitely stated that they will not use the library unless its released as a stable version to be part of the Scala Platform, because one of the main points of the library is interoperability (which you can’t get if you need to release a new dependency).
If there is an intention for a library to be part of the Scala Platform and interoperability is one of the libraries main goals of the library (as well as the library being a common dependency for other libraries) then its going to be a lot less painful (and more convincing) for library authors to use the library when its part of SP, because they know they won’t need to update the dependency.
Note that the current Scala Platform Process document says of modules, “Platform modules should stress stability and usability alike, and enjoy widespread use in the Scala community. Modules should be of a nature that aids the goal of the Scala Platform and should have compatible licenses with the rest of the Platform modules.”
It doesn’t define the words “should” and “must” and so on, but normally the words should and recommended refer to things that are not absolutely necessary but count against a proposal or implementation. I think it’s totally fair for the lack of widespread use presently for scala-json-ast to count against it, but I don’t think it’s fair for that to knock it out of consideration without further examination, especially in light of expressed interest.
No, the need for a standard library in the Scala Platform isn’t lessened just because there’s a library that is already widely used. The batteries still aren’t included until it’s in.
I don’t think we should just dismiss that the “wide adoption” part is missing. Even if it is a chicken-and-egg situation with respect to this particular library, it nonetheless raises somewhat more concern when something isn’t battle-tested.
But when you really need these kind of batteries, it’s worth examining things that one can reasonably expect to be widely used. The question for the committee is whether it fits the goals of the Scala Platform so well that the lack strict adherence to every single guidelines (they are guidelines!) should be overlooked.
And I agree that in this particular case, adoption is a chicken-and-egg situation. It’s very clear that it is: the library authors who might adopt it have flat out said so, repeatedly.
I am not trying to completely “dismiss” the point, I am just saying its relevance is dependant on context of the SPP.
The current design of the AST, for example, is a slightly altered one which many projects have used (its based off the original json4s/spray JSON design). So although you can claim that it doesn’t have widespread adoption, at the same time its not as if its never been used before. Other points is that its design is very trivial (as opposed to, lets say, a HTTP library or a collections library).
Some of the battle testing has already been done, just under a different name. I also suspect that once there is an indication of its approval, library authors will use the library in the next milestone of the major release, where it will undergo a lot of testing.
My point was that the relevance of widespread adoption was dependent on context! I’m not sure whether we’re agreeing, or whether you’re going one level more meta.
Anyway, I don’t think in practice we particularly disagree. I just think that the discussion should be along the lines of “it is worth it because” rather than “it’s totally irrelevant” w.r.t. adoption.
The incubation period is the perfect moment for gathering developers around your library, creating a community, cleaning up APIs (note that changes in public APIs cause binary incompatibility and are done every year and a half), accepting PRs, creating well-documented issues that people can work on, et cetera.
Library maintainers accept Scala Center’s Code of Conduct and use it in their projects.
Library maintainers decide the license they will use (they can stay with the same they have).
Library maintainers decide whether they endorse C4 or not.
Libraries have Gitter channels and pertinent CONTRIBUTION guidelines for people to submit paches/PRs!
Remember that taking decisions on these issues is extremely important for creating a community around the modules – our end goal! You can also participate in the current open debates to abstain from recommending C4 / MPLv2 or changing the major cycle to one year instead of 18 months; your opinion is highly valuable, so please comment.
At the Scala Center, we’re planning to run a series of hackathon in well-known Scala conferences to encourage people to hack on open issues of Scala Platform modules and join their community. Our goal is to boost the success of the Platform and help us get to a point where we can all benefit from a high-quality collection of modules. This is why having CONTRIBUTION guidelines, tips to developers and a getting started guide is important – consider writing them.
Scala JSON AST
In the case of this proposal, there has been a lot of interest to have a published jar available under an official group id. Matthew showed interest in our last meeting to use something along the lines of org.scala-lang.modules. I’m currently figuring out the official name for modules with the Lightbend team, but another suggestion would be org.scala-lang.platform. I’ll let you know the final group id that will be fetchable from Maven.
Regarding infrastructure, I’ll contact library maintainers to make the transition in the next days. Thank you very much for getting involved in this collaborative effort to improve the experience of Scala developers all around the world.
Would like to announce that the first release of scalajson on the proper organization and package name has occurred, you can view the details in the github repo here https://github.com/mdedetrich/scalajson (tl;dr the dependency is now "org.scala-lang.platform" %% "scalajson" % "1.0.0-M1" and "org.scala-lang.platform" %%% "scalajson" % "1.0.0-M1" for scala.js)
I wrote down a few notes about how spray-json could integrate with scalajson here: https://github.com/spray/spray-json/issues/232. I think it would be good if the scalajson project itself would give a few suggestions how to integrate.
I guess, so far, the simple “shallow” integration is the most likely outcome for spray-json.
I wonder if it is too late to make any substantial changes to the proposal? My suggestions would be removing the unsafe AST and not providing a concrete implementation of the AST at all but only interfaces of the AST nodes for json libraries to implement. What do other maintainers of other json libraries say? (See the discussion for circe here: https://github.com/circe/circe/issues/690#issuecomment-311956866) Is this a forum where json library maintainers could discuss these things?