Given all of this, I think it’s clear that ScalaCheck would benefit from more maintainers, and in fact there’s a 2 years old issue asking for that, where a plan to make a scalacheck organization was brought up but hasn’t been implemented so far.
To unblock the situation, I propose that we move scalacheck to the scala organization on github, this is less work than creating a brand new organization, and it guarantees that at no point in the future will the situation be bottlenecked like this again. Concretely, either a Scala org admin (@SethTisue ?) need to give @rickynils the necessary rights to move scalacheck, or @rickynils needs to make a Scala admin maintainer so that they can move the repo themselves.
There will be a lot of follow-up questions once this is done (e.g., should scalacheck be published under a different organization? If so, can we get scala-steward to ease the migration?), but I think that we should first focus on moving the repo, and that we can figure out everything else later, once people can start merging PRs again.
Does that seem like a good plan ?
PS: If you’re interested in recommending a different property checking library or calling for a new one to be written, please make a new topic to discuss that, the linear nature of Discourse means that we have to keep threads focused if we want them to be useful discussion tools.
ScalaCheck is in dire need of more maintenance and the way practically all the libraries at the root of most dependency trees (Cats, Shapeless, etc.) use ScalaCheck is a pretty good indicator to me that moving it to the Scala org is a good idea
ScalaCheck is a very fine library, and has served the Scala community well over the years. More recently, there has been quite a lot of innovation in the property testing space, ranging from free shrinking to permutative / perturbation testing to exhaustive checking to type class-free designs. In this context, the design of ScalaCheck is showing signs of aging.
Moving ScalaCheck into scala and maintaining backward compatibility is one solution to the dependency problem, but given the space is ripe for continued evolution, it may not represent the best possible timing for such a move; nor is any one property checking library necessarily a core piece of Scala infrastructure, at least to the same extent as the compiler or standard library.
Instead, I would suggest that the pain of depending on ScalaCheck may represent a good forcing function for library authors to evaluate newer alternatives, such as Scala Hedgehog; alternatives that are likely to be increasingly favored in the years to come.
Hey folks, I’m at a work event so I have limited bandwidth.
I was added as a maintainer of ScalaCheck but for a few reasons I haven’t done a great job of improving this situation:
I’ve had less time for open-source over the last few years.
ScalaCheck doesn’t have a standard release process, so only Rickard can currently do releases.
Given the amount of past documentation produced for ScalaCheck (including a book) I have been reluctant to radically change or break the API to address issues such as shrinking. (Binary compatibility is also an issue here.)
I haven’t felt empowered to add other maintainers to the project (I’m not sure if I have permission or not).
I’m interested to hear from Rickard on this. If he’s fine moving the project I think that’s a good idea, and I trust @SethTisue to manage things like the release process.
Unrelatedly, this is a good wake-up call. Independent of this proposal I’ll see if I can get publishing rights and try to unblock things.
That may be true, but I think there is still the glaring problem that everything either directly or indirectly depends on scalacheck and because of this it needs stable maintainers. People obviously can choose newer alternatives but this will take a long time.
I agree with the solution of putting scalacheck into the Scala org
If the project moved to another organization on Github and Sonatype (either Typelevel or Scala) then it would widen the range of people who could administer the project, publish releases, etc.
While I wouldn’t be opposed to seeing ScalaCheck move to the Scala org, having Typelevel adopt it seems more appropriate (and equally good), to me. It’s a Typelevel member project, and Typelevel has a pool of people (including, at times, me) who can do releases and such.
(“Adopt” = on GitHub and on Sonatype, as Erik indicates.)
@mdedetrich As of 3.1.0 ScalaTest will not depend on ScalaCheck anymore. We moved the ScalaCheck integration out to a separate project that depends on both. That severed the dependency and also allows new versions of the integration project to be released whenever either has a binary incompatible release. We also have created a built-in generator that will not be public in the API in 3.1.0, but should come out soon after.
I’m personally strongly in favour of this. There are a bunch of people who are usually active and willing to run releases under org.typelevel, even for projects they don’t maintain themselves.
So talking to Rickard, it sounds like he plans to move the project to Typelevel, as per the suggestions of @SethTisue et al.
At that point, if we fix up the build to support sbt-release etc. we should be able to cut a new release ASAP (published to org.typelevel instead of org.scalacheck).
That’s great news. But before publishing under a new org, let’s open an issue to discuss the eviction and bincompat implications. The ecosystem is still migrating to 0.14 and we need to be very careful how we do this.
