v0.6.0 Release Plan and Date
jdantonio opened this issue · 14 comments
TL;DR I think we should remove ActorContext from the master branch and release 0.6.0 ASAP, possibly as soon as 5/25.
A quick look at the changelog shows that we have implemented a ton of great stuff since the 0.5.0 release. The only thing we're waiting on that was planned for 0.6.0 is a new actor implementation. Since I've changed direction on that (again, more on this later) I think we should remove that from the roadmap for 0.6.0. We've marked the current Actor implementation as deprecated but haven't removed it. We lose nothing if we release 0.6.0 without a new actor implementation, but we deny our community access to many great updates if we continue to hold back.
A further discussion of actors can be found in this thread.
Thoughts?
I will merge in fork-join and the fork-join-executor within a week for 0.6.
@chrisseaton Thank you. If for some reason you aren't able to finish that's OK. There is plenty of great stuff ready for this release already.
Sounds good to me. I'll extract some of the minor improvements I did in #73 to new PR for 0.6.
@jdantonio I am close to merge #73 would it make sense to include it into 0.6 as experimental feature?
@pitr-ch How stable and reliable is it? And will there be a name collision if we have both the old and new actors in the gem at the same time? (We had discussed naming it something other than Actress.)
The 0.6.0 release has a ton of stuff in it so it will give our users plenty of cool new features. But we've also deprecated the old Actor class in this release. It would be nice to have one release that has both the old actor and the new, to provide for a transition. But I think it's more important to release a new actor system that won't fundamentally change, only grow more robust.
It is not production ready, but I would not call it fragile. I did see no weird concurrency errors. I think it would be fine releasing that as experimental to public.
Then we could incrementally harden it with 0.6.x releases until it's ready for 0.7. Yep the names are colliding, what about:
- 0.6 With deprecated old Actor and Actress
- 0.7 Actor replaced with Actress, Actress is alias
- 0.8 Actress name removed completely
Another way would be just deprecate Actor in 0.6 (as it already is) and release actress as an experimental concurrent-ruby extension and including that to 0.7 when it is ready. It would also allow more rapid releasing of concurrent-ruby-actress gem. (better to have the organization in place for that)
Interesting conundrum. I definitely don't want to create a temporary gem.
What the heck. Let's merge it, document it as experimental, use the warn function to make sure our users know it is experimental, remove "ActorContext" from the warning messages in Actor, and follow your suggested 0.6/0.7/0.8 plan.
- changelog done
@pitr-ch Some of the actress test code was experiencing deadlocks on both my local machine and on various Travis builds. I marked the actress tests pending and commented a few out. I also added an experimental warning message to the spawn and spawn! factory methods.
ALL: I'm not sure what happened to Supervisor but it is experiencing many test failures on Travis. The only recent change was when I moved the error classes into a central location. Oddly, none of the Supervisor tests failed with that merge. The problems just started today. I'll take a look at those tests and try to figure out what's going on. I think I may deprecate it and Runnable in future releases.
I've made changes to spec_helper.rb not to reconfigure Concurrent.configuration and kill all threads on each spec by default but only where needed. I wanted to investigate it more before merge but I did not made it in time. What failures did you see? Could you send me a gist? I saw only one failing test which I was investigating.
I'll work on fixing this, we could release 0.6.1 after that.
@pitr-ch The call to subjects.each on line 83 of actress_spec.rb often runs forever, even when all the specs are marked pending. I'll take a look at the changes to spec_helper. Some of the tests (like Supervisor are now generating a large number of threads that do not get killed. The thread.kill ... that used to be in spec_helper was, admittedly, very brute force, but it kept us from leaking threads. We need to identify which test suites were affected and fix them.
Thanks I'll try to duplicate it.
I have a feeling I should have communicated better about the status of the Actress merge branch. I've considered it feature ready but I still had todos on my list including the weird tests' behavior. I would not have merged it. But when you did I let myself thought that you've conspired the changes alright. Anyway I mark my PRs clearly next time and sorry for the complications.
Sorry about this. It's my mistake. We had talked about releasing over the weekend so I assumed that branch was ready. I should have explicitly asked first.