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:

• Make class declarations public to enable save and replay of shrinked command sequences #143
• Display more helpful failure information in Commands API #426
• Shrinking command data #728
• Improve shrinking of Command sequences and allow customization #632
• Fail at generating Command sequences less often #633
• Make printing of Commands failures more readable #634

[jonaskoelker]

Here are a few more open issues:

• Ensure preconditions are satisified when shrinking Commands actions #739
• Enable customization of Commands.Command shrinking #740

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