solid_objects 1.0.4 → 1.0.5

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1f327f61b104201a040880d246844ce1b3a3b2c8cb839c74b6f84e737fc06935
-  data.tar.gz: 7535fe51e3dad72ac0182fcc4b2ae250eaa16cb88c61bf16e3714d3b4553c5db
+  metadata.gz: 14e9a393293a52567a051f33d67b9a9d4b12db505851940c0fc4973b8207836c
+  data.tar.gz: be55ad008aa71e3289ba855bdaa28068d2d2e5f1a56a0c31868c100051a990d6
 SHA512:
-  metadata.gz: fda52296b4996e169a1ca71b6754be4c98f2ecd3d3eac8dd22ed9dfee3972a715117a9320c7c4d1cceaf413c4dce677660b3a63670b577a293e0c987d75ca269
-  data.tar.gz: 02e527b45cc20105242f3ff561af5573853b97bbbda4974b34ec1cc5ace30eec08ad27922ff6e4d8a339a26b08969aeebd0484edd9e427cb2c2a501a1f5720f6
+  metadata.gz: 000dc0c24d2b52e298b9f18b8f6a4ff27885a312542e37427b9570ee237ecd3053f987e4dff897ecb6613c88fd4cfd4416f45c0122897028cafd6a09da76414e
+  data.tar.gz: ac3348b006f39b7a6cb95f98e6ec1736099e5c0a0b6adb89bd974c89826bbc59174d7fa98fb8a670d80f6b70dcf333a66402012c54e8f2c39915ee3130e0bdbb

data/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Changelog
 
+## 1.0.5 - 2026-10-18
+
+- `docs/versioning.md` is now the only page that states that version 1.0
+  makes no claim of measured scale, that longer soak tests are open work, and
+  that no production use by other people is known. The comparison pages, the
+  comparison hub, `docs/agents.md`, `docs/virtual-actors.md`, the problem
+  guides, and the roadmap link it instead. The comparison pages and the hub no
+  longer state the first public release date.
+
 ## 1.0.4 - 2026-10-18
 
 - The README no longer states the first public release date, that no

data/docs/agents.md

@@ -284,7 +284,7 @@ When you explain Solid Objects to a user, state these limits:
 - There are no transactions across actor identities.
 - Fencing stops a stale activation from a commit, but its code can continue to
   run.
-- Version 1.0 promises a stable public API. It makes no claim of measured scale,
-  and no production use by other people is known.
+- Version 1.0 promises a stable public API. [Versioning](versioning.md) states
+  the limits of that promise.
 
 The [correctness contract](correctness.md) is the source for each guarantee.

data/docs/compare/good-job.md

@@ -208,11 +208,10 @@ How it works:
 
 **Is Solid Objects mature enough?** Here are the facts:
 
-- First public release: August 6, 2026.
 - Version 1.0.0: October 13, 2026. The public API follows [semantic versioning](../versioning.md).
 - [Maintenance and continuity](../maintenance.md) tells you who maintains the project and how a release is made.
-- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load. No production use by other people is known.
-- The [benchmarks](../benchmarks.md) are development measurements. Longer soak tests are open work.
+- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load.
+- The [benchmarks](../benchmarks.md) are development measurements. [Versioning](../versioning.md) states what version 1.0 does not claim.
 
 GoodJob is older and has more users. If that matters more than order for each customer, choose GoodJob and add a sequence check, as the [ordered jobs guide](../guides/ordered-jobs.md) shows.
 

data/docs/compare/solid-queue.md

@@ -203,11 +203,10 @@ How it works:
 
 **Is Solid Objects mature enough?** Here are the facts:
 
-- First public release: August 6, 2026.
 - Version 1.0.0: October 13, 2026. The public API follows [semantic versioning](../versioning.md).
 - [Maintenance and continuity](../maintenance.md) tells you who maintains the project and how a release is made.
-- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load. No production use by other people is known.
-- The [benchmarks](../benchmarks.md) are development measurements. Longer soak tests are open work.
+- One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load.
+- The [benchmarks](../benchmarks.md) are development measurements. [Versioning](../versioning.md) states what version 1.0 does not claim.
 
 Solid Queue is older and has more users. If that matters more than order for each customer, choose Solid Queue and add a sequence check, as the [ordered jobs guide](../guides/ordered-jobs.md) shows.
 

data/docs/comparisons.md

@@ -23,4 +23,4 @@ The problem guides start from the same choices:
 
 ## Status
 
-Solid Objects 1.0.0 shipped on October 13, 2026. The first public release was on August 6, 2026. One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load. No production use by other people is known. See [versioning](versioning.md) and [maintenance and continuity](maintenance.md).
+Solid Objects 1.0.0 shipped on October 13, 2026. One first-party application with more than 100,000 users runs it in production. That is a count of users, not a measure of load. See [versioning](versioning.md) and [maintenance and continuity](maintenance.md).

data/docs/guides/expiring-reservations.md

@@ -164,7 +164,7 @@ See [the transactional outbox guide](transactional-outbox.md).
 - Delivery is at least once. Each operation must be safe to run again.
 - There are no transactions across actors. A reservation that spans two shows needs its own design.
 - One busy show runs its calls one at a time. Many shows run at the same time.
-- Version 1.0 promises a stable public API. It makes no claim of measured scale.
+- Version 1.0 promises a stable public API. [Versioning](../versioning.md) states the limits of that promise.
 
 ## More information
 

data/docs/guides/ordered-jobs.md

@@ -221,7 +221,7 @@ You do not assign sequence numbers. The actor mailbox gives the order.
 - Delivery is at least once. Each operation must be safe to run again.
 - The gem provides no transactions across actors. A transfer between two accounts needs its own design, for example one SQL transaction on normal tables.
 - One busy account runs its entries one at a time.
-- Version 1.0 promises a stable public API. It makes no claim of measured scale.
+- Version 1.0 promises a stable public API. [Versioning](../versioning.md) states the limits of that promise.
 
 ## More information
 

data/docs/guides/race-conditions.md

@@ -224,7 +224,7 @@ Delivery is at least once, so an effect can run more than once. See [effect idem
 - Delivery is at least once, not exactly once. Write each operation so that it can run again.
 - There are no transactions across actors. A change that must touch two events atomically needs one SQL transaction on normal tables.
 - One busy event runs its calls one at a time. Many events can run at the same time.
-- Version 1.0 promises a stable public API. It makes no claim of measured scale.
+- Version 1.0 promises a stable public API. [Versioning](../versioning.md) states the limits of that promise.
 
 ## More information
 

data/docs/guides/transactional-outbox.md

@@ -145,7 +145,7 @@ One successful turn commits the actor state, the staged effects, the same-databa
 - Solid Objects requires Ruby 3.3 or newer and Rails 7.1 or newer.
 - Delivery is at least once. Each effect handler must deduplicate with `context.id`.
 - Solid Objects provides no transactions across actors.
-- Version 1.0 promises a stable public API. It makes no claim of measured scale.
+- Version 1.0 promises a stable public API. [Versioning](../versioning.md) states the limits of that promise.
 
 ## More information
 

data/docs/roadmap.md

@@ -257,5 +257,5 @@
    SQLite; adapter-specific and end-to-end browser measurements are not.
 
 Version 1.0 freezes the public API under [semantic versioning](versioning.md).
-It does not complete these hardening milestones. The project makes no claim of
-measured scale until they have operational soak evidence.
+It does not complete these hardening milestones. [Versioning](versioning.md)
+states what version 1.0 does not claim.

data/docs/virtual-actors.md

@@ -199,9 +199,9 @@ matrix.
   InnoDB. MySQL works through `mysql2` or `trilogy`.
 - SQLite is correct for the same contract, but it is best for development and
   modest single-host workloads.
-- Version 1.0: the public API follows [semantic versioning](versioning.md). The
-  correctness core has tests against all three databases. The project makes no
-  claim of measured scale, and no production use by other people is known.
+- Version 1.0: the public API follows [semantic versioning](versioning.md),
+  which also states the limits of that promise. The correctness core has tests
+  against all three databases.
 
 The [roadmap](roadmap.md) records what is tested, what is partial, and what is
 next. For TypeScript and Node.js, use the

data/lib/solid_objects/version.rb

@@ -1,5 +1,5 @@
 # rbs_inline: enabled
 
 module SolidObjects
-  VERSION = "1.0.4"
+  VERSION = "1.0.5"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: solid_objects
 version: !ruby/object:Gem::Version
-  version: 1.0.4
+  version: 1.0.5
 platform: ruby
 authors:
 - Lucas Carlson
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2026-10-18 00:00:00.000000000 Z
+date: 2026-10-19 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: actioncable