1.0 Release

[xaviershay]

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?

[colszowka]

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 Safari rendering issues #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.

[colszowka]

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

[bf4]

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?

[xaviershay]

Sounds like a plan. I'm away for a week, but will jump in where I can when I get back.

[sferik]

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

[bf4]

Feel free to use or not the wip branches i pushed last night: json, jruby

[Ch4s3]

Are any of these things still up for grabs? I use simplecov a lot and would love to help out.

[bf4]

@Ch4s3 sure. Sorry we've dropped the ball on this.

[sferik]

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.

[xaviershay]

👏 👏 👏

[colszowka]

Nice, thanks @sferik !

[sferik]

I’m going to work on replacing shoulda with RSpec now. Wish me luck!

[colszowka]

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

[colszowka]

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.

[Ch4s3]

@colszowka what specifically can be done to help towards 1.0?