diff --git a/README.md b/README.md
index 8f95d8be..0bd8959a 100644
--- a/README.md
+++ b/README.md
@@ -878,17 +878,15 @@ To perform upgrades to the GoodJob database tables:
 
 GoodJob v4 changes how job and job execution records are stored in the database; moving from job and executions being commingled in the `good_jobs` table to separately and discretely storing job executions in `good_job_executions`. To safely upgrade, all unfinished jobs must use the new format. This change was introduced in GoodJob [v3.15.4 (April 2023)](https://github.com/bensheldon/good_job/releases/tag/v3.15.4), so your application is likely ready-to-upgrade already if you have kept up with GoodJob updates.
 
-**⚠️GoodJob v4.0.0 and v3.99 have not yet been released, though you can still prepare for the upgrade.**
-
 To upgrade:
 
-1. ~~Upgrade to v3.99.x, following the minor version upgrade process, running any remaining database migrations (rails g good_job:update) and addressing deprecation warnings.~~ (Not yet released)
+1. Upgrade to v3.99.x, following the minor version upgrade process, running any remaining database migrations (rails g good_job:update) and addressing deprecation warnings.
 1. Check if your application is safe to upgrade to the new job record format by running either:
     - In a production console, run `GoodJob.v4_ready?` which should return `true` when safely upgradable.
     - Or, when connected to the production database verify that `SELECT COUNT(*) FROM "good_jobs" WHERE finished_at IS NULL AND is_discrete IS NOT TRUE` returns `0`
 
     If not all unfinished jobs are stored in the new format, either wait to upgrade until those jobs finish or discard them. Not waiting could prevent those jobs from successfully running when upgrading to v4.
-1. ~~Upgrade from v3.99.x to v4.x~~ (Not yet released)
+1. Upgrade from v3.99.x to v4.x.
 
 Notable changes:
 
diff --git a/app/models/good_job/base_execution.rb b/app/models/good_job/base_execution.rb
index d2be5d58..4dc6d6c3 100644
--- a/app/models/good_job/base_execution.rb
+++ b/app/models/good_job/base_execution.rb
@@ -310,11 +310,10 @@ def self.build_for_enqueue(active_job, overrides = {})
 
     # Construct arguments for GoodJob::Execution from an ActiveJob instance.
     def self.enqueue_args(active_job, overrides = {})
-      if active_job.priority && GoodJob.configuration.smaller_number_is_higher_priority.nil?
+      if active_job.priority && GoodJob.configuration.smaller_number_is_higher_priority.in?([nil, false])
         GoodJob.deprecator.warn(<<~DEPRECATION)
           The next major version of GoodJob (v4.0) will change job `priority` to give smaller numbers higher priority (default: `0`), in accordance with Active Job's definition of priority.
             To opt-in to this behavior now, set `config.good_job.smaller_number_is_higher_priority = true` in your GoodJob initializer or application.rb.
-            To not opt-in yet, but silence this deprecation warning, set `config.good_job.smaller_number_is_higher_priority = false`.
         DEPRECATION
       end
 
diff --git a/spec/app/models/good_job/execution_spec.rb b/spec/app/models/good_job/execution_spec.rb
index 0699d427..2604ac64 100644
--- a/spec/app/models/good_job/execution_spec.rb
+++ b/spec/app/models/good_job/execution_spec.rb
@@ -143,10 +143,10 @@ def perform(result_value = nil, raise_error: false)
       context 'when smaller_number_higher_priority=false' do
         before { allow(Rails.application.config).to receive(:good_job).and_return(smaller_number_is_higher_priority: false) }
 
-        it 'does not warn' do
+        it 'warns to ensure the upgrade is obvious' do
           active_job.priority = 50
           described_class.enqueue(active_job)
-          expect(GoodJob.deprecator).not_to have_received(:warn)
+          expect(GoodJob.deprecator).to have_received(:warn)
         end
       end
     end