Future of the commands API

[ashawley]

ScalaCheck introduced the commands API at ScalaDays 2014 in Berlin and was first released in version 1.12. It was never documented in the ''ScalaCheck: The Definitive Guide'' published a year before. However, it is documented pretty well in the User Guide.

The command API has been relatively stable. It has grown a small user base (the same could be said for ScalaCheck broadly). We've had a few users contribute fixes that obviously weren't caught by the single test for commands. In the spirit of minimizing the scope of ScalaCheck per #351, should the commands API be deprecated and moved to a separate project?

We have a few open issues and a couple of significant improvements in the queue. It's a part of the library I don't have a lot of experience with, so I'm hesitant to make many changes that break compatibility. We could try to make breaking changes to the commands API as part of the 2.0 effort, but we may not have the long-term capacity for that.

[ashawley]

Here's the current open issues:

• https://github.com/typelevel/scalacheck/issues/143
• https://github.com/typelevel/scalacheck/issues/426
• https://github.com/typelevel/scalacheck/issues/728
• https://github.com/typelevel/scalacheck/pull/632
• https://github.com/typelevel/scalacheck/pull/633
• https://github.com/typelevel/scalacheck/pull/634

[jonaskoelker]

Here are a few more open issues:

• #739
• #740

Those two are fragments of #632. If they are applied together with one more follow-up, #632 can be closed.