Consider calling it 1.0 sooner?
jrochkind opened this issue · 2 comments
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!
Thank you, @jrochkind, for the suggestion. I think you make a very good point. Our 1.0 roadmap has been very loose but it's time we get more specific. None of the in-progress features are essential. They are mostly additive. For me, the three big things that are essential for a 1.0 release are:
- Verify that the new setup for C extensions introduced in 0.8.0 is working for the community and they way we want to keep the gems structured moving forward
- Complete the internal refactoring of out "future-like" abstractions proposed by @pitr-ch in #176
- Decide how and when we will merge the
thread_safegem, as per the discussion in #230 (I don't think this merge has to happen before 1.0, but we should all agree first)
Thoughts? @pitr-ch @mighe @chrisseaton @lucasallan @obrok @rkday