Update splitting functions

[isaacvando]

The Str and List splitting functions will be renamed and expanded once the next nightly is released. CI will fail until the new nightly is released. We will also need to upgrade some of the packages to use new versions.

[Anton-4]

We will also need to upgrade some of the packages to use new versions.

I'll take care of that

[Anton-4]

./bin/verify-exercises passes locally, so this should be ready to go once the current TESTING nightlies become the latest nightlies :)

[Anton-4]

Done :)

[isaacvando]

Awesome, thank you @Anton-4!!

I just opened a PR to upgrade the dependencies in the test runner also exercism/roc-test-runner#19 but CI is failing right now. I don't have to time to figure out the issue now, but hopefully I will be able to later today or this weekend.

It would be good to have both of these changes out close to each other to minimize the time the track is broken. Unfortunately I'm not sure if there's a way for us to release the test runner and track in a non-breaking way since the changes in the compiler themselves are breaking and we have to release two different artifacts. If there is a way and I'm missing please let me know.

[isaacvando]

Alright the test runner PR is now good to go also

[Anton-4]

I've confirmed that Str.splitOn works on the exercism website 🎉

[isaacvando]

Great, thanks again Anton!

[ageron]

Thanks for taking care of this!

It might be possible to include two (or more) Roc releases in the test runner, and add a configuration file in the roc track to specify which Roc version to use. This way we could add a new Roc version in the test runner, push it, then add a new exercise in the Roc track using the new version, and push the track.

That said, it feels like too much work for a fairly rare and limited disruption. Wdyt?

[Anton-4]

Updating on breaking releases is already a lot of work, so I'd love to minimize work where we can :)

[IsaacG]

Thanks for taking care of this!

It might be possible to include two (or more) Roc releases in the test runner, and add a configuration file in the roc track to specify which Roc version to use. This way we could add a new Roc version in the test runner, push it, then add a new exercise in the Roc track using the new version, and push the track.

That said, it feels like too much work for a fairly rare and limited disruption. Wdyt?

Hard to say without knowing how much work it is and how reliable that would be 🙂

If it's relatively easy and stable, it might be a good addition. Sometimes you don't know how much work something is until you try to build/prototype it.