QueueClassic 3.2

[smathieu]

After discussing it with @jipiboily we think that the current RC release should be release as 3.1 as-is baring the discovery of a critical bug.

I'm opening this to discuss what should be included in the 3.2 release (which I hope we can release a beta version of soon).

Personally, I'd like to see:

• Proposed interface change to QC::Queue #249 new interface for Queue
• QC is not thread safe #247 Thread Safety / Puma support
• Count in QC::Queue returns scheduled jobs too #246 Return correct count of jobs

Thoughts @senny , @jipiboily ?

[jipiboily]

This looks like a nice plan to me!

[senny]

@smathieu seems fine. Note that I already pushed some structural refactorings to master. They aim for backwards compatibility but I haven't reached my goals yet. As commented I'd like to further change the way a connection is acquired.

[senny]

I'm wondering though. Releasing QC with a known threading issue seems careless.

Instead we could release one more RC as the final artifact of 3.1. basically never treating it as final and head for a quick 3.2.0.RC1.

Thoughts?

[jipiboily]

3.1 was released by @smathieu a couple of days ago. The threading issue is not new, it was probably there "forever".

This sounds like a good plan for 3.2 to me...or even 4.0 if there is a lot of refactoring and APIs?

Can you guys think of a major feature you would like to see in a 4.0? I personally think the core of what qc should do is in place, I would love to see improvements mostly, not that many new features. I like that's it has a tight scope.

[smathieu]

For me, in 4.0.0 we should mostly focus on fixing the API. I'd like to see a well documented and minimal interface to QC. I feel that this use to be the case, but overtime, the introductions of new features diluted that.

I think that the introduction of workers that can work on multiple queues, although very useful, broke the semantics of the API. Operations like count if now very confusing. I'd also like to see the new DDL I proposed in #252 as well as some work done on performance. I think we're lacking an index on scheduled_at and the lock_head method has an extra COUNT query that might affect performance.

[senny]

Agree with @smathieu plans for 4.0. We don't need to introduce new stuff (we can do that in minor releases). The focus should be on reaching a solid API.

[jipiboily]

I'm on board with that plan!

[senny]

@smathieu @jipiboily what are our current release plans? I think #257 would be worth releasing.

[senny]

@jipiboily ping. What are the plans? There are some nice improvements on master that I think we should release sometime. Anything blocking from your side of things?

[jipiboily]

yeah, we should have a release soon, at least with the bug fix submitted today. Nothing blocking on my end.

That being said, I have NOT worked with QC since I left Rainforest back in September and I don't have any work planned with it so it's unlikely that I'll be able to dedicate time to it, at least not on the short term. I'm swamped over. If you need a hand on something specific, feel free to ping me, happy to jump on a quick call if you want to bounce off ideas.

[senny]

@jipiboily I could do the release but I have no permissions on rubygems.

[jipiboily]

@senny oh, I can fix that for you! I'll DM you on Twitter.

[senny]

@smathieu @jipiboily I'll be releasing an RC of QC 3.2 from the current master. While the points made in this issue have not been addressed I still think we need to make another public release. Let me know if you have any objections.

[jipiboily]

👍

[olleolleolle]

Would it be too forward to place a note about the 3.2 RC in the README?

Update: I added CHANGELOG.md content.