v0.6.0 Release Plan and Date

[jdantonio]

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?

[chrisseaton]

I will merge in fork-join and the fork-join-executor within a week for 0.6.

[jdantonio]

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

[pitr-ch]

Sounds good to me. I'll extract some of the minor improvements I did in #73 to new PR for 0.6.

[pitr-ch]

@jdantonio I am close to merge #73 would it make sense to include it into 0.6 as experimental feature?

[jdantonio]

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

[pitr-ch]

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)

[jdantonio]

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.

[jdantonio]

@pitr-ch Once you merge Actress, please add a few notes to the changelog

[pitr-ch]

• changelog done

[jdantonio]

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

[pitr-ch]

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.