Question: What are the requirements to be out of beta?
Closed this issue · 5 comments
I've used the rspec library for a couple of pet projects currently, and I haven't really found any issue with it. Why are the cargo releases still beta?
Thank you for using Rspec, it's very nice to hear ! :)
Because we want to be able to break the API as we want as it's still in development.
It was a mistake on my part, honestly. I should just have made it a 0.1 and increment from that.
Currently, the API can't be stabilized because we are still experimenting with formatters, contextes, and how it interacts with the runner. Some of it could be, but I don't have the time nor the experience to untangle the parts.
Thank you for using Rspec, it's very nice to hear ! :)
This. So much this! 😍
To add some more context to @mackwic's answer:
If you take a look at issue #29 you will see that quite a lot has been happening all around rspec.
The tasks that are still open/WIP are:
Timing & Progress
Difficulty: Both 1) and 2) are of medium difficulty/complexity.
Breaking changes: I expect neither of them to be a source-breaking change.
Progress: 1) has not been started yet. 2) is partially implemented.
Filtering & Focussing
Difficulty: Again, both 1) and 2) are of medium difficulty/complexity.
Breaking changes: Depending on how we decide to implement there might be a source-breaking change.
Progress: Just two days ago I pushed an experimental implementation to the dedicated experiments repo.
Parallel & Async Tests
This is probably best suited for a dedicated micro-crate.
Difficulty: n/a
Breaking changes: None to be expected.
Progress: n/a
Ergonomics
Difficulty: This is a big one. The difficulty here comes with not being allowed to use any unstable features of Rust. Otherwise we could "just" write a syntax extension.
Breaking changes: All of them.
Progress: Just two days ago I pushed an experimental implementation to the dedicated experiments repo.
Integration
- Integration with rustc's test crate
Difficulty: Another big one. The biggest of all, actually. And as far as I see it this won't sail without making several changes to how cargo test works. This will require us to write up an RFC, get it accepted, write a water-proof implementation, and last but not least to get it stabilized. As I said, it's a big one.
Breaking changes: Again, all of them.
Progress: Nothing yet, frankly.
So, to sum things up: We aren't halfway where we would like to see rspec eventually. And especially until those two remaining majorly source-breaking features/refactors have been resolved there is little use in going 1.x from my point of view.
In case you're interested, I gave a talk on the things I recently worked on, on rspec and what it took to get it to where it is now, standing on the shoulders of giants (aka @mackwic's existing work):
rspec – Making a BDD framework in stable Rust
Oct 18th 2017, Berlin (Rust-Berlin Meetup)
- Video: Mozilla Air | YouTube
(the audio is missing during the first few minutes)- Slides: Deckset | PDF
Thanks for the Reply. I definitely will look into seeing what I can do to contribute to the projejct.
This is great! Also apart from actual code contributions be reminded that contributions to the documentation of the code and/or APIs are much appreciated. (Just as are comments à la “this part right here could really use some inline documentation. I have no idea what it’s doing.” of which there will be many, I presume. We want rspec to be as approchable as possible, while providing a rich feature set.)
Oh and something else I’d really, really appreciate is feedback from you (and basically anybody using rspec or considering using it) on the parts of rspec that we did well (and thus should try to not mess with in future refactorings/changes), as well as those parts that don’t quite feel as polished or that you consider outright unusable at the moment. Without feedback we’re at risk of overfitting rspec to our (@mackwic & me) own needs.
as nice as this issue is, I think we can close it.