1.0 Release #320

Open
xaviershay opened this Issue Jul 17, 2014 · 21 comments

Comments

Projects
None yet
8 participants
@xaviershay
Collaborator

xaviershay commented Jul 17, 2014

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

This comment has been minimized.

Show comment Hide comment
@colszowka

colszowka Jul 17, 2014

Owner

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

colszowka commented Jul 17, 2014

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

This comment has been minimized.

Show comment Hide comment
@colszowka

colszowka Jul 17, 2014

Owner

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

Owner

colszowka commented Jul 17, 2014

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

This comment has been minimized.

Show comment Hide comment
@bf4

bf4 Jul 18, 2014

Collaborator

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?
Collaborator

bf4 commented Jul 18, 2014

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

This comment has been minimized.

Show comment Hide comment
@xaviershay

xaviershay Jul 18, 2014

Collaborator

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

Collaborator

xaviershay commented Jul 18, 2014

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

@sferik

This comment has been minimized.

Show comment Hide comment
@sferik

sferik Jul 18, 2014

Collaborator

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

Collaborator

sferik commented Jul 18, 2014

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

This comment has been minimized.

Show comment Hide comment
@bf4

bf4 Jul 18, 2014

Collaborator

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

Collaborator

bf4 commented Jul 18, 2014

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

@Ch4s3

This comment has been minimized.

Show comment Hide comment
@Ch4s3

Ch4s3 Oct 27, 2014

Contributor

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

Contributor

Ch4s3 commented Oct 27, 2014

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

@bf4

This comment has been minimized.

Show comment Hide comment
@bf4

bf4 Jan 28, 2015

Collaborator

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

Collaborator

bf4 commented Jan 28, 2015

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

@sferik

This comment has been minimized.

Show comment Hide comment
@sferik

sferik Apr 18, 2015

Collaborator

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.

Collaborator

sferik commented Apr 18, 2015

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

This comment has been minimized.

Show comment Hide comment
@xaviershay

xaviershay Apr 18, 2015

Collaborator

👏 👏 👏

Collaborator

xaviershay commented Apr 18, 2015

👏 👏 👏

@colszowka

This comment has been minimized.

Show comment Hide comment
@colszowka

colszowka Apr 18, 2015

Owner

Nice, thanks @sferik !

Owner

colszowka commented Apr 18, 2015

Nice, thanks @sferik !

@sferik

This comment has been minimized.

Show comment Hide comment
@sferik

sferik Apr 18, 2015

Collaborator

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

Collaborator

sferik commented Apr 18, 2015

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

@colszowka

This comment has been minimized.

Show comment Hide comment
@colszowka

colszowka Apr 18, 2015

Owner

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

Owner

colszowka commented Apr 18, 2015

@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

This comment has been minimized.

Show comment Hide comment
@colszowka

colszowka Apr 18, 2015

Owner

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.

Owner

colszowka commented Apr 18, 2015

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

This comment has been minimized.

Show comment Hide comment
@Ch4s3

Ch4s3 Apr 19, 2015

Contributor

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

Contributor

Ch4s3 commented Apr 19, 2015

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

@onebree

This comment has been minimized.

Show comment Hide comment
@onebree

onebree Apr 20, 2015

Contributor

In regards to #320 (comment):

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.

Contributor

onebree commented Apr 20, 2015

In regards to #320 (comment):

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

This comment has been minimized.

Show comment Hide comment
@Ch4s3

Ch4s3 Apr 20, 2015

Contributor

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

Contributor

Ch4s3 commented Apr 20, 2015

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

@onebree

This comment has been minimized.

Show comment Hide comment
@onebree

onebree Apr 20, 2015

Contributor

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

Contributor

onebree commented Apr 20, 2015

@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

This comment has been minimized.

Show comment Hide comment
@ptashman

ptashman Apr 22, 2015

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

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

@PragTob

This comment has been minimized.

Show comment Hide comment
@PragTob

PragTob Jan 25, 2017

Collaborator

👋

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

Collaborator

PragTob commented Jan 25, 2017

👋

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

This comment has been minimized.

Show comment Hide comment
@PragTob

PragTob Feb 4, 2017

Collaborator

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

Collaborator

PragTob commented Feb 4, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment