Repository navigation
docs: describe the PR and tag release flow - #88
Merged
Merged
Conversation
The Release Workflow section told the maintainer to commit and push main. No release does that. Each release since August went through a pull request, and the tag went on the merge commit. The section now gives the real steps in order: the prepare commit in a pull request, the documentation check, the local gate, the merge conditions, the tag on the merge commit, and the site deploy. It also states the version rule that applies before 1.0. The example tag command uses a placeholder and not a real version number.
|
Docs7 for cardmagic/solid-objects-ruby
Commit |
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The "Release Workflow" section of AGENTS.md told the maintainer to commit and push
main, and then to push a tag. No release does that. Each release since August went through a pull request. An agent that obeyed the old text would push a release commit directly tomain.What changed
Only AGENTS.md changed. The "Release Workflow" section now gives the real steps in order:
chore: prepare version X.Y.Zcommit in a pull request updateslib/solid_objects/version.rb, theCHANGELOG.mdsection for the version, andGemfile.lock.docs/virtual-actors.mdanddocs/agents.mdagainst the release. The old section had this step, and it stays.bundle exec rakeruns before the push.main. The example command uses the placeholdervX.Y.Zand not a real version number.solid-objects-tag-to-prodskill updates and deploys solidobjects.dev. Thecheck:releasesentence and the Context7 sentence from the old section stay.The section also states the version rule before 1.0: a feature or a behavior change gets a minor version, and a fix gets a patch version.
Effects
docs/roadmap.mdedit. The change edits prose only.Tests
This change has no production code, so it has no new test and no quoted failing test output. No test reads AGENTS.md.
Validation
Command:
bundle exec rakeon commit ee0f9aa, rebased on origin/main (8c9f0f9).921 runs, 3507 assertions, 1 failures, 1 errors, 28 skips.EffectRecoveryTest#test_a_running_effect_keeps_its_process_heartbeat_fresh:Expected: "processing" Actual: "completed".VerticalSliceTest#test_sync_returns_a_durable_result_without_another_worker:SolidObjects::SyncTimeout: actor invocation timed out after 2 seconds.27 runs, 97 assertions, 0 failures, 0 errors, 8 skips.921 runs, 3514 assertions, 0 failures, 0 errors, 28 skips. RuboCop:304 files inspected, no offenses detected. Steep:No type error detected. Brakeman:Security Warnings: 0.The two failures in run 1 are not related to this change. A follow-up task records them. The cause is not proven. The hypothesis is that each test depends on a short wall-clock threshold.
The 28 skips occur in each run on SQLite. I did not examine them, because this change does not touch an adapter.