Consider calling it 1.0 sooner? #246
Description
I am already using concurrent-ruby in production apps myself, which I feel comfortable doing based on observed/tested robustness of the code; sufficient features for what I need; observed attention to backwards compat concerns already in your development; and your encouragement that it is indeed suitable for production use already.
I understand that you're waiting on more features for a 1.0 release -- but if people are using it in production already (and I think it makes sense to do so), would it make sense to call it 1.0 already, with the features coming in a future 1.x (if backwards compat) or 2.0?
http://semver.org recommends:
How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
But making it 1.0 would be an active commitment to maintain backwards compat until 2.0 -- maybe you're not quite ready to make that commitment? But making that commitment might make people more comfortable using the software in production -- a 0.x release sends the message "not ready for production", which I think is not actually the message you intend to be sending? (And I think intentionally sending the message 'ready for production' does responsibly require a commitment to maintaining backwards compat to some extent)
I think since 0.7.0 was probably when it's realistic to consider a ready-for-production 1.0 release. (Especially with addition of fallback policies for ThreadPools). And I think the API has stabilized a lot in 0.7 and 0.8 for the features that are there, and it may be reasonable now to commit to backwards compat?
Just a suggestion for discussion, I realize there may be reasons!