All Versions
47
Latest Version
Avg Release Cycle
107 days
Latest Release
63 days ago

Changelog History
Page 1

  • v2.0.0.beta1 Changes

    March 24, 2022

    ๐Ÿš€ Preliminary release of Ruby 3 support

    Notable changes:

    • ๐Ÿ‘Œ Support for Ruby 3 introduced
    • ๐Ÿ‘ท Database schema has changed to split the job arguments args column into args and kwargs columns, for reliable args and kwargs splitting for Ruby 3.
      • The job schema version is now 2. Note that job schema version is distinct from database schema version and Que version. The job_schema_version column of the que_jobs table no longer defaults and has a not null constraint, so when manually inserting jobs into the table, this must be specified as 2. If you have a gem that needs to support multiple Que versions, best not to blindly use the value of Que.job_schema_version; instead have different code paths depending on the value of Que.job_schema_version. You could also use this to know whether keyword arguments are in args or kwargs.
    • ๐Ÿ‘ท Passing a hash literal as the last job argument to be splatted into job keyword arguments is no longer supported.
    • ๐Ÿ‘ท Dropped support for providing job options as top-level keyword arguments to Job.enqueue, i.e. queue, priority, run_at, job_class, and tags. Job options now need to be nested under the job_options keyword argument instead. See #336
    • โฌ‡๏ธ Dropped support for Ruby < 2.7
    • โฌ‡๏ธ Dropped support for Rails < 6.0
    • โฑ The #by_args method on the Job model (for both Sequel and ActiveRecord) now searches based on both args and kwargs, but it performs a subset match instead of an exact match. For instance, if your job was scheduled with 'a', 'b', 'c', foo: 'bar', baz: 1, by_args('a', 'b', baz: 1) would find and return the job.
    • ๐Ÿš€ This release contains a database migration. You will need to migrate Que to the latest database schema version (6). For example, on ActiveRecord and Rails 6:
    class UpdateQueTablesToVersion6 < ActiveRecord::Migration[6.0]
      def up
        Que.migrate!(version: 6)
      end
    
      def down
        Que.migrate!(version: 5)
      end
    end
    

    โฌ†๏ธ Recommended upgrade process:

    ๐Ÿ‘ท When using Que 2.x, a job enqueued with Ruby 2.7 will run as expected on Ruby 3. We recommend:

    โฌ†๏ธ 1. Upgrade your project to the latest 1.x version of Que (1.3.1+) - IMPORTANT: adds support for zero downtime upgrade to Que 2.x, see changelog below โฌ†๏ธ 2. Upgrade your project to Ruby 2.7 and Rails 6.x if it is not already โฌ†๏ธ 3. Upgrade your project to Que 2.x but stay on Ruby 2.7 - IMPORTANT: You will need to continue to run Que 1.x workers until all jobs enqueued using Que 1.x (i.e. with a job_schema_version of 1) have been finished. See below โฌ†๏ธ 4. Upgrade your project to Ruby 3

    NOTES:

    • If you were already running Ruby 2.7 and were not passing a hash literal as the last job argument, you may be able to upgrade a running system without draining the queue, though this is not recommended.
    • โฌ†๏ธ For all other cases, you will need to follow the recommended process above or first completely drain the queue (stop enqueuing new jobs and finish processing any jobs in the database, including cleaning out any expired jobs) before upgrading.

    ๐Ÿš€ Deploying Que 1.x and 2.x workers simultaneously:

    ๐Ÿ‘ท To run workers with two different versions of Que, you'll probably need to temporarily duplicate your gem bundle, with the Que version being the only difference. e.g.:

    • ๐Ÿ”’ Copy your Gemfile and Gemfile.lock into a directory called que-1-gemfile
    • Set a suitable Que version in each Gemfile
    • โšก๏ธ Update the bundle at que-1-gemfile/Gemfile.lock using BUNDLE_GEMFILE=que-1-gemfile/Gemfile bundle
    • ๐Ÿš€ Create a second deployment of Que, but with your que command prefixed with BUNDLE_GEMFILE=que-1-gemfile/Gemfile

    โฌ†๏ธ We'd appreciate feedback on your experience upgrading to and running Que 2. Feel free to post on our Discord, or if you run into trouble, open an issue on GitHub.

  • v1.4.0 Changes

    March 23, 2022
    • ๐Ÿ›  Fixed
      • The poller will no longer sleep when jobs exist for only some of its priorities. It now skips sleeping when a poll returns more jobs than the lowest priority requested. #349.
        • An alternative was considered which skipped polling when only some of the waiting worker priorities would be fully utilised (diagram explanation); but this was decided against for code complexity reasons. #348
    • ๐Ÿ—„ Deprecated:
      • Deprecated --minimum-buffer-size option. It was not actually used, and will be removed in v2.0.0. #346
        • It became used in 1.0.0.beta4, and that changelog entry has been updated to reflect this.
    • ๐Ÿ“š Documentation:
      • Reformatted the changelog to be more consistent, including adding links to all issue/PR numbers. #347
  • v1.3.1 Changes

    February 25, 2022

    โฌ†๏ธ Unfortunately, v1.3.0 was broken. Follow its upgrade instructions, but use this version instead.

    • ๐Ÿ›  Fixed
      • Fixed startup error: undefined method 'job_schema_version' for Que:Module, in #343
  • v1.3.0 Changes

    February 25, 2022

    ACTION REQUIRED

    ๐Ÿš€ This release will allow you to safely upgrade to Que 2 when it comes out, without first needing to empty your que_jobs table.

    ๐Ÿš€ You will need to first update to this version, apply the Que schema migration, and deploy, before you can safely begin the process of upgrading to Que 2.

    ๐Ÿ‘ท Que 2 will bring Ruby 3 support, but to do that, the job arguments in the que_jobs table will need to be split into two columns - repurposing the existing one for positional arguments only (args), and adding a new one for keyword arguments (kwargs). This is so that Que running in Ruby 3, when reading job arguments stored in the database, can disambiguate between keyword arguments and a last positional argument hash.

    โฌ†๏ธ The args split hasn't happened yet, but when it does, we still need to be able to successfully process all the existing queued jobs which have their keyword arguments in the args column still. Our solution is for you to have both Que 1 workers and Que 2 workers operating simultaneously during the upgrade, each processing only the jobs enqueued from that version. Once all the Que 1 jobs are processed, the Que 1 workers can be retired.

    ๐Ÿ‘ท To allow the different worker versions to tell which jobs belong to which, we've added a new column to the que_jobs table in this version, job_schema_version. Jobs enqueued with Que 1 will have a 1 here, and jobs from Que 2 will have a 2. Que schema migration 5 will default the job schema version of all existing jobs to 1.

    โœ… You will need to migrate Que to the latest Que schema version (5). For instance, on ActiveRecord and Rails 6:

    class UpdateQueTablesToVersion5 < ActiveRecord::Migration[6.0]
      def up
        Que.migrate!(version: 5)
      end
      def down
        Que.migrate!(version: 4)
      end
    end
    

    ๐Ÿš€ You must apply the schema migration and deploy to upgrade all workers.

    ๐Ÿš€ No further action is required from you at this stage. The Que 2 release changelog will provide full upgrade instructions for the process briefly described above of simultaneously running both Que 1 & 2 workers. Note that you won't be required to upgrade from Ruby 2.7 to Ruby 3 at the same time as upgrading to Que 2.

    โšก๏ธ If you use any Que plugins or custom code that interacts with the que_jobs table, before you can upgrade to Que 2, you will need to make sure they are updated for compatibility with Que 2: They'll need to make use of the kwargs column, and when inserting jobs, put a 2 into the job_schema_version column rather than continue to rely on its soon-to-be-removed default of 1.

    Other improvements:

    • ๐Ÿ”‹ Features:
      • Log config on startup, in #337
    • Internal:
      • Added Git pre-push hook, in #338
      • Documented our gem release process, in #341
  • v1.2.0 Changes

    February 23, 2022
    • ๐Ÿ—„ Deprecated
      • Providing job options as top level keyword arguments to Job.enqueue is now deprecated. Support will be dropped in 2.0. Job options should be nested under the job_options keyword arg instead. See #336
  • v1.1.0 Changes

    February 21, 2022
    • ๐Ÿ”‹ Features:
    • Internal:
      • Add Dockerised development environment, in #324
  • v1.0.0 Changes

    January 17, 2020

    ๐Ÿš€ This release does not add any changes on top of 1.0.0.beta5.

  • v1.0.0.beta5 Changes

    December 23, 2021

    Full Changelog: v1.0.0.beta4...v1.0.0.beta5

    ๐Ÿš€ Unless an issue is found we intend for this release to become v1.0.0 proper.


  • v1.0.0.beta4 Changes

    January 17, 2020
    • ๐Ÿ“œ Rails 6 compatibility: Fix time parsing #249 and 5ddddd5
    • Cleaner sequel usage, in #257
    • ๐Ÿ“š Documentation improvements: #264, #269, #261, #231
    • The --minimum-buffer-size option is now unused
  • v1.0.0.beta3 Changes

    May 18, 2018
    • โž• Added support for customizing log levels for job_worked events (#217).
    • ๐Ÿ‘ท Began logging all job_errored events at the ERROR log level.
    • ๐Ÿ›  Fixed the Railtie when running in test mode (#214).
    • ๐Ÿ‘ท Tweaked the meanings of worker-priorities and worker-count options in the CLI, to better support use cases with low worker counts (#216).