Prepare Swift-JSON 1.0.0 release

CHANGELOG.md

@@ -1,6 +1,8 @@
 # Changelog
 
-## Unreleased
+## 1.0.0 — 2026-10-11
+
+First stable release.
 
 - Public GitHub Pages documentation with four native DocC references; the exact
   artifact publishes from `main` after native, safety and documentation CI pass.
@@ -30,9 +32,9 @@
 Qualification details and counts are in Documentation/Qualification/README.md. Resource
 policy bounds logical work/ownership; it is not an operating-system RSS ceiling.
 E09 keeps scalar scanning and no retained scratch pool. SIMD and regex prefilters
-remain unselected; projection and RFC 7464 framing remain deferred. No version tag or release has been created.
+remain unselected; projection and RFC 7464 framing remain deferred.
 
-### Candidate verification refinements
+### Exact coding and public reports
 
 - Reject lossy native String-dictionary and changed CodingKey spelling projections.
 - Add exact JSONObject Codable round-trips and a raw-schema compile report that

README.md

@@ -13,9 +13,9 @@ partially read document would change the meaning of your data.
 
 [Read the documentation →](https://thorfuchs.github.io/Swift-JSON/)
 
-Maintained by [Thorsten Fuchs](https://github.com/ThorFuchs). The repository is public;
-**version 1.0.0 has not yet been tagged or released**. Until a version is published,
-use `main` and retain the resolved commit for reproducible builds.
+Maintained by [Thorsten Fuchs](https://github.com/ThorFuchs). Swift-JSON follows
+semantic versioning. Use a released version and retain `Package.resolved` for
+reproducible builds; `main` tracks ongoing development.
 
 ## Why Swift-JSON?
 
@@ -75,7 +75,7 @@ packages.
 Add the package to your `Package.swift`:
 
 ```swift
-.package(url: "https://github.com/ThorFuchs/Swift-JSON.git", branch: "main")
+.package(url: "https://github.com/ThorFuchs/Swift-JSON.git", from: "1.0.0")
 ```
 
 Then add products to your target dependencies:
@@ -86,9 +86,10 @@ Then add products to your target dependencies:
 ```
 
 Add `JSONStreaming` and `JSONPatch` in the same way when needed. A local checkout can
-use `.package(path: "../Swift-JSON")`. After a release is published, select a semantic
-version requirement. See the [four-product consumer](Examples/Consumer) for a
-complete buildable manifest.
+use `.package(path: "../Swift-JSON")`. The requirement above accepts compatible 1.x
+releases. See the [four-product consumer](Examples/Consumer) for a complete buildable
+manifest. The website tracks `main`; release assets include compiled DocC catalogues
+for the exact released source.
 
 ## Parse, inspect and write exact values
 

RELEASING.md

@@ -1,7 +1,8 @@
 # Release process
 
-No version tag or GitHub release exists yet. Maintainer: @ThorFuchs. Publication
-requires a separate explicit instruction; CI never creates tags or releases.
+Maintainer: @ThorFuchs. Version tags use semantic versions such as `1.0.0`.
+Publication requires an explicit maintainer instruction; CI never creates tags
+or releases. Published version tags are protected against updates and deletion.
 
 1. Require passed native, safety and documentation lanes for the exact candidate
    commit on macOS/SDK 27+ and Swift 6.4+ with language mode 6.
@@ -20,6 +21,14 @@ requires a separate explicit instruction; CI never creates tags or releases.
    `Scripts/ci.py --lane native`.
 6. Retain source identity, environment, command exits, nonzero counts and receipts.
    Verify private reporting, support routes and branch protections.
+7. Create an annotated version tag at the exact qualified commit. Check its target
+   before pushing: published tags cannot be moved. Prepare release notes, the source
+   archive, the matching compiled DocC archive, a public qualification receipt and
+   SHA-256 checksums. Upload only reviewed public assets; private maintainer records
+   remain outside Git and the public release.
+8. Verify the release assets against the checksum file and confirm that a separate
+   SwiftPM consumer resolves the version tag. A draft release is preparation;
+   publish it only when publication has been explicitly requested.
 
-Tagging 1.0.0 and creating its release are deliberate maintainer actions after
+Creating a version tag and its GitHub release are deliberate maintainer actions after
 this review. A successful CI run alone does not authorize them.

SECURITY.md

@@ -18,11 +18,10 @@ no response-time or remediation SLA is promised.
 
 ## Supported versions
 
-Once the first stable release exists, security and defect fixes target the latest
+Security and defect fixes target the latest
 published **1.x** release. Older patch/minor versions should upgrade to that release.
 No backport or extended-support commitment is made for older release lines.
-Before 1.0.0 is released, the current `main` candidate receives best-effort fixes;
-there is no published stable version yet. See [SUPPORT.md](SUPPORT.md).
+See [SUPPORT.md](SUPPORT.md) for the maintenance policy.
 
 ## Boundaries
 

SUPPORT.md

@@ -6,9 +6,8 @@ defects, documentation corrections and focused feature proposals. For security
 reports, use the private route in [SECURITY.md](SECURITY.md).
 
 The stable support policy is **the latest published 1.x release**. Fixes are shipped
-in that line; users of older 1.x versions should upgrade. Before the first stable
-release, `main` is a candidate with best-effort maintenance. There is currently no
-1.0.0 tag or GitHub release. No paid support, response-time SLA or older-line
+in that line; users of older 1.x versions should upgrade. The `main` branch tracks
+development and receives best-effort maintenance. No paid support, response-time SLA or older-line
 backport commitment is implied.
 
 The package requires Swift tools/compiler 6.4+, Swift language mode 6 and