Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: What are the requirements to be out of beta? #43

Closed
JustinRyanH opened this issue Oct 25, 2017 · 5 comments
Closed

Question: What are the requirements to be out of beta? #43

JustinRyanH opened this issue Oct 25, 2017 · 5 comments
Labels

Comments

@JustinRyanH
Copy link

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?

@mackwic
Copy link
Member

mackwic commented Oct 25, 2017

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.

@regexident regexident changed the title Quesiton: What are the requirements to be out of beta? Question: What are the requirements to be out of beta? Oct 26, 2017
@regexident
Copy link
Collaborator

regexident commented Oct 26, 2017

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

  1. Formatter: Progress à la Fuubar
  2. Timing the tests (WIP)

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

  1. Skipped tests and describes
  2. Focused tests and describes

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

  1. 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

  1. Get rid of ctx in ctx.it()

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

  1. 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)

@JustinRyanH
Copy link
Author

Thanks for the Reply. I definitely will look into seeing what I can do to contribute to the projejct.

@regexident
Copy link
Collaborator

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.

@mackwic
Copy link
Member

mackwic commented Oct 28, 2017

as nice as this issue is, I think we can close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants