release 1.0.0 and follow semver

[nevans]

Although we claim semver, we still don't have a version 1.0.0 (which is required for semver). :)

If everything goes well with the RC I pushed last night, I'll make that 0.5.0 next Tuesday. I've held off on v1.0.0 because of the many warts, but since I've been using this in production (as-is) for several years, I think those warts aren't enough to prohibit a first release.

What will hold off a public release is if there is if there are any backwards compatible changes that "need" to be made. I'd rather make them now than make a 1.0 release that is only supported for a couple of weeks/months (or backport bugfixes).

If there are no backwards-incompatible changes to be made, I'll just rename 0.5.0 as 1.0.0 a week or so after 0.5.0 is released.

[nevans]

In particular, I'd like to analyze the most significant or longest lived forks and see if there's anything we need to merge from them that might impact backwards compatibility. If so, let's merge them before 1.0.0. If not, we can merge them for 1.1 or 1.2.

After a quick perusal of the fork-network (most of which have been inactive for over a year), these seem to be the most significant branches that haven't sent in pull requests (and some that have):

• backupify/resque-pool@nevans:master...master
  • mostly @haruska, also @nirvdrum, @ericalexander, @bpovlich, @james-lawrence
• ShippingEasy/resque-pool@nevans:master...deploy @joshuaflanagan and @brasic
• PeopleAdmin/resque-pool@nevans:master...deploy (and other branches)
  • @joshuaflanagan, @lwoodson, @mattdbridges
• jonleighton/resque-pool@nevans:master...hooks @jonleighton
• mcwiklinski/resque-pool@nevans:master...master @mcwiklinski
• af83/resque-pool@nevans:master...af83 @spk and @nono
• optimis/resque-pool@nevans:master...drb @uchouhan
• optimis/resque-pool@nevans:master...v3 @uchouhan
• maxdunn210/resque-pool@nevans:master...master @maxdunn210
• ono/resque-pool@nevans:master...master @ono
• What other significant forks are we missing?

This is not a commitment to merge in every single change they've made (we might want to make their changes easy to do as plugins or configuration rather than core part of resque-pool). It's a commitment to research them for backwards incompatibility, and plan the shortest course to semver 1.0.0 (that won't require us to release 2.0.0 in order to support what these forks are doing).

[haruska]

I'm unsure if backupify is still using resque-pool. That said, those changes to ensure you don't 2x your worker count on restart are probably still valuable to those using resque.

[ono]

Thanks for the heads-up. We wanted to monitor memory usage of each worker processes with monit. Monit requires pid file and my patch gives the sequential name like resuque-pool.worker.1.pid, resuque-pool.worker.2.pid... to pid files. It also considers when a worker process gets killed and resque-pool spawn a process again. In that case, it has to rewrite the existing pid file instead of creating a new one.

The reasons I didn't send PR were:

1. implementation is hacky
2. the use case is limited so I supposed that you didn't want to maintain

Besides we are also sunsetting a sub-system which is currently using it. So please don't worry about my fork.

[joshuaflanagan]

The significant work in the PeopleAdmin/ShippingEasy forks has already been
submitted as a PR:
#85

I still think that PR has widespread value and should be pulled in. We are
still actively using our forks.

On Tue, Feb 3, 2015 at 4:48 PM, Tatsuya Ono notifications@github.com
wrote:

Thanks for the heads-up. We wanted to monitor memory usage of each worker
processes with monit. Monit requires pid file and my patch gives the
sequential name like resuque-pool.worker.1.pid, resuque-pool.worker.2.pid...
to pid files. It also considers when a worker process gets killed and
resque-pool spawn a process again. In that case, it has to rewrite the
existing pid file instead of creating a new one.

The reason I didn't send PR was:

1. implementation is hacky
2. the use case is limited so I supposed that you didn't want to
   maintain

Besides we are also sunsetting a sub-system which is currently using it.
So please don't worry about my fork.

—
Reply to this email directly or view it on GitHub
#120 (comment).

[nevans]

The most important of these branches (custom config loader) was merged and released in 0.6.0.rc1. Please help test it (and the other changes) out, if you can.

[joshuaflanagan]

I'll try to get this release deployed soon, to test. For what its worth, the custom config loader code has been running in production at 2 different companies for over a year. One company uses the custom config loader feature, and the other relies on the default yml file config, and both scenarios have been running fine with that code.

[phuongnd08]

Sorry for being nosy, but how that custom config loader would benefit the mass?

[joshuaflanagan]

@phuongnd08 A lot of teams are constrained by the static yaml configuration. See #69, #62, and #99 as some examples of people trying to work around the static config. The custom config loader offers an extension point to solve all of those problems, without requiring resque-pool to take on code specific to those solutions.

[phuongnd08]

Thank you. Perhaps I could use this to tackle #136

[phuongnd08]

Just to clear thing up: If number of worker assigned to a queue is currently 1, on a configuration reload I set it to 0, would it terminate the current executing task or would it wait until the task completed?