search

simplecov-ruby / simplecov

Code coverage for Ruby with a powerful configuration library and automatic merging of coverage across test suites
MIT License
4.75k stars 551 forks source link

1.0 Release #320

Open xaviershay opened 10 years ago

xaviershay commented 10 years ago

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 commented 10 years ago

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:

colszowka commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

sferik commented 10 years ago

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 commented 10 years ago

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

Ch4s3 commented 9 years ago

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

bf4 commented 9 years ago

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

sferik commented 9 years ago

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 commented 9 years ago

:clap: :clap: :clap:

colszowka commented 9 years ago

Nice, thanks @sferik !

sferik commented 9 years ago

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

colszowka commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

onebree commented 9 years ago

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 commented 9 years ago

How about Gitter. A few other projects I work on use it and its quite nice.

onebree commented 9 years ago

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

ptashman commented 9 years ago

I too would love to help out for a 1.0 release.

PragTob commented 7 years ago

: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? :)

PragTob commented 7 years ago

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

PragTob commented 5 years ago

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:

PragTob commented 4 years ago

And thanks to Ruby Together the chances that this happens by early next year has gone up drastically.

No promises of course :crossed_fingers:

IMG_20190127_150119