simplecov
simplecov copied to clipboard
simplecov-ruby
1.0 Release
SimpleCov is used by many people, and has been around awhile. Has a 1.0 (semver) release been considered? If yes, what is blocking it?
See this little exchange I had with @bf4 on twitter on this topic.
Basically, I've always waited it for it to become perfect. As the author of this project, I've come to know all the warts and rough spots of the code base that I'd love to get rid of before dubbing it 1.0, but probably something around v0.6 should already have been deemed worthy of 1.0 years ago since the project and it's APIs have been pretty stable.
One thing I always wanted to have was full and official JRuby support. The Coverage library there has some minor differences, but the cucumber test suite would pass if it wouldn't time out on Travis after 45 minutes due to the many subprocesses being fired up there, which take ages on JRuby. I tried to figure this out by speeding up the jvm boot time, but it didn't help much.
I would suggest the following Roadmap:
- Get the current master with the important exit status fix out as 0.9 ASAP. I think we should get #270 resolved as soon as possible as well.
- Get rid of all Ruby 1.8-related code and maybe some other workarounds like the tweaks for old JRuby versions to clean up the code base a bit. Ship that as 1.0.0.rc1 and dub it 1.0 when no show stoppers appear.
Another thing I wanted to tackle for ages was getting rid of the shoulda-based unit test suite and replacing that with RSpec unit tests, but I guess this is an internal change and should not be blocking the 1.0 label. I'd also like to move some specific use cases and examples from the README to some separate guides/docs files, but the same thing regarding 1.0 dubbing applies here.
Maybe we can also get rid of the multi-Gemfile appraisal backed test setup, it is only there because multi_json changed it's API at some point and simplecov needed to support both. We could either consider ditching multi_json in favor of the stdlib json library (I gather it is now stable on JRuby?) or just support multi json versions after the API change. It's been over two years I think, people should have upgraded by now :) This would cut the test suite run time by 50%.
All rubies now have a 'json' library, so it would be safe to just require 'json' and then JSON.whatever. That said, it might be might to put a really thin wrapper around it in case someone want to use a different JSON engine.
I don't think 270 should block a 1.0.0, though it would be nice to prioritize it.
I would prefer to say 1.0.0 does not support 1.8, even if the code hasn't been removed yet, just to speed things along.
I think opening the wiki would be a good idea for people to share ideas.
I'm gong to update the README with a brief blurb at the beginning to check the CONTRIBUTING section before making an issue, and write or link there about the very common load order issue, and maybe more-strongly recommend a .simplecov
## Contact
*Code and Bug Reports*
* [Issue Tracker](https://github.com/colszowka/simplecov/issues)
* See [CONTRIBUTING](https://github.com/colszowka/simplecov/blob/master/CONTRIBUTING.md) for how to contribute along with some common problems to check out before creating an issue.
*Questions, Problems, Suggestions, etc.*
* TBD: Mailing list? Google group? Nabble? Wiki?
Sounds like a plan. I'm away for a week, but will jump in where I can when I get back.
Now that we have the new multi-formatter interface I’d like to see the old interface deprecated in an 0.9.x release and removed in 1.0.0.
Switching from shoulda to RSpec 3 shouldn’t be a blocker. I can help work on that conversion.
As a former maintainer of MultiJSON, I’d recommend switching away from it, in favor of the json stdlib, as soon as Ruby 1.8 support dropped (along with Appraisal).
Are any of these things still up for grabs? I use simplecov a lot and would love to help out.
Okay, I’ve removed the multi_json dependency and shipped 0.10.0. Hopefully, this will be the last minor release before 1.0.0.
@sferik Awesome, good luck :)
I've been eyeing a refactoring of some internals for a while now, especially I'd love to make the result merging and rendering steps easier to call in isolation and/or programmatically without being so tighly knit to the result collection part. If you bump into something that is very hard to test, we should probably have a look at refactoring it soon.
To elaborate a bit more on this, probably we should keep bigger changes out of the current stable version to ship it as 1.0, and then do some cleanups as a 2.0 tree, since at the moment simplecov is pretty rock-solid in most cases and even though I'm somewhat unhappy with some parts of the code base, it has been battle-tested by many, many people and a lot of weird edge cases and special scenarios are handled by it.
What is annoying me most right now is that it is quite hard to generate a coverage report manually from source files and a corresponding coverage result, which for example makes it very hard to create (and test) report formatters. It should probably be clearer what parts of simplecov are in charge of collecting and storing coverage data and what parts do the actual report generation.
In regards to https://github.com/colszowka/simplecov/issues/320#issuecomment-49386755:
I think that with a 1.0 release, it is important to have some sort of discussion room. While IRC is nice and easy, some may be wary of using it in the workplace. (I know I would.) To accommodate everyone, it would be good to have an open discussion using Google Groups -- or even something nicer. I find that other projects use Google Groups, but very few maintain it well.
@Ch4s3 I forgot about that one! I agree that it is a great idea, especially since it has mobile apps and push notifications. Gitter is much more SFW since it is strictly about github repos.
:wave:
There might be JRuby support now, multi_json is gone, there is just one Gemfile (save the test projects), there's no shoulda...
Internally there might be #450 and I haven't looked at all PRs/issues yet + dunno how much simplecov time I'll take/give myself but maybe 2017 could be the year of all years for this to happen? :)
Mental note, dropping the json gem dependency seems to be a big thing for lots of people, so might be cool to do as well along with dropping compatibility with a couple of ruby versions.
#511 #458
Clearly 2017 was not the year for this to happen. 2019 might be it. Probably 2020+ if we're being realistic.
My current plan, ofc depending on my time is:
- [x] drop EOL'ed ruby support (accomplised)
- [x] merge branch coverage #694
- [x] give it a couple of releases to test out branch coverage
- [x] upgrade our dev dependencies like cucumber/aruba etc.
- [ ] fix bigger outstanding issues (new rails parallelization + x might be a problem, need to get through all issues first I guess)
- [x] all the things on the HTML formatter side (haven't even really looked at it yet much tbh :'( )
And thanks to Ruby Together the chances that this happens by early next year has gone up drastically.
No promises of course :crossed_fingers:
