sm-upgrade: Gem Upgrade Workflow
Guides AI agents through upgrading SourceMonitor in a host Rails application after a new gem version is released. Covers CHANGELOG review, running the upgrade command, interpreting verification results, handling deprecation warnings, and resolving common edge cases.
When to Use
- Host app is updating the source_monitor gem version in Gemfile
- User reports deprecation warnings after a gem update
- User wants to know what changed between versions
- Troubleshooting a broken upgrade
- Migrating configuration after breaking changes
Prerequisites
| Requirement | How to Check |
|---|---|
| Existing SourceMonitor installation | cat .source_monitor_version or check config/initializers/source_monitor.rb |
| Access to CHANGELOG.md | Bundled with gem: bundle show source_monitor then read CHANGELOG.md |
| Current gem version known | grep source_monitor Gemfile.lock |
Upgrade Workflow
- Review CHANGELOG -- Read
CHANGELOG.mdin the gem source. Identify changes between the current installed version (from.source_monitor_versionorGemfile.lock) and the target version. Focus on Added, Changed, Fixed, Removed sections. Flag any breaking changes or deprecation notices. - Update Gemfile -- Bump the version constraint in the host app's Gemfile:
gem "source_monitor", "~> X.Y". Runbundle update source_monitor. - Run the upgrade command --
bin/rails source_monitor:upgrade. This automatically: detects the version change via.source_monitor_versionmarker, copies new migrations, re-runs the install generator (idempotent), runs the full verification suite. - Run database migrations --
bin/rails db:migrateif the upgrade command copied new migrations. - Handle deprecation warnings -- If the configure block in the initializer uses deprecated options, Rails logger will show warnings at boot. Read each warning, identify the replacement, update the initializer. See
sm-configureskill for configuration reference. - Run verification --
bin/rails source_monitor:setup:verifyto confirm all checks pass. - Restart processes -- Restart web server and Solid Queue workers to pick up the new version.
Interpreting Upgrade Results
The upgrade command runs 4 verification checks automatically:
| Check | OK | Failure | Fix |
|---|---|---|---|
| PendingMigrations | All engine migrations present | Missing migrations need copying | bin/rails db:migrate |
| SolidQueue | Workers running | Workers not detected | Start Solid Queue workers via Procfile.dev or bin/rails solid_queue:start |
| RecurringSchedule | Tasks registered | Tasks missing from dispatcher | Re-run generator or check config/queue.yml |
| ActionCable | Adapter configured | No production adapter | Configure Solid Cable or Redis adapter |
Handling Deprecation Warnings
The deprecation framework uses two severity levels:
:warning-- Option renamed. The old name still works but logs a deprecation message. Update the initializer to use the new option name. The message includes the replacement path.:error-- Option removed. Using the old name raisesSourceMonitor::DeprecatedOptionError. You must remove or replace the option before the app can boot.
Pattern for fixing deprecations:
- Read the deprecation message (logged to
Rails.loggeror raised as an error) - Find the replacement option path in the message
- Update
config/initializers/source_monitor.rb - Restart and verify the warning is gone
Example deprecation message:
[SourceMonitor] DEPRECATION: 'http.old_option' was deprecated in v0.5.0 and replaced by 'http.new_option'.
Edge Cases
- First install (no
.source_monitor_versionfile): Upgrade command treats this as a version change and runs the full workflow. Safe to run on first install. - Same version (no change): Command reports "Already up to date (vX.Y.Z)" and exits cleanly.
- Skipped versions (e.g., 0.2.0 to 0.4.0): Read all CHANGELOG sections between the two versions. Multiple migrations may need running.
- Failed verification after upgrade: Read the verification output. Most common: pending migrations (run
db:migrate), missing Solid Queue workers (start workers), stale recurring schedule (re-run generator). - Custom scrapers or event handlers: Check CHANGELOG for API changes in
Scrapers::Baseor event callback signatures.
Key Source Files
| File | Purpose |
|---|---|
lib/source_monitor/setup/upgrade_command.rb |
Upgrade orchestrator |
lib/source_monitor/setup/cli.rb |
CLI entry point (Thor, used in development) |
lib/source_monitor/setup/verification/runner.rb |
Verification runner (4 verifiers) |
lib/source_monitor/configuration/deprecation_registry.rb |
Deprecation framework |
CHANGELOG.md |
Version history (Keep a Changelog format) |
.source_monitor_version |
Version marker in host app root |
References
docs/upgrade.md-- Human-readable upgrade guidedocs/setup.md-- Initial setup documentationdocs/troubleshooting.md-- Common issues and fixessm-host-setupskill -- Initial installation workflowsm-configureskill -- Configuration reference for updating deprecated options
Checklist
- CHANGELOG reviewed for version range
- Gemfile updated and
bundle update source_monitorrun -
bin/rails source_monitor:upgradecompleted successfully - Database migrations applied if needed
- Deprecation warnings addressed in initializer
-
bin/rails source_monitor:setup:verifypasses all checks - Web server and workers restarted