Reconcile version identity and make the untagged state honest

CHANGELOG.md

@@ -4,11 +4,14 @@ All notable changes to smithy-cpp are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versions follow the
 policy in [docs/versioning.md](docs/versioning.md).
 
-## [0.1.0] - 2026-07-07
+## [Unreleased]
 
-The first tagged release: a vendor-neutral Smithy → C++ code generator, the
-runtime it targets, and Bazel-native consumption — with every generated
-surface conformance-tested and integration-tested in CI.
+The 0.1.0 milestone: a vendor-neutral Smithy → C++ code generator, the runtime
+it targets, and Bazel-native consumption — with every generated surface
+conformance-tested and integration-tested in CI. Developed on `main` and
+**not yet tagged**; the runtime reports `0.1.0-dev` until the first signed
+release (see [docs/versioning.md](docs/versioning.md)). Consumers pin a commit
+via `git_override` until then.
 
 ### Protocols
 
@@ -54,4 +57,4 @@ surface conformance-tested and integration-tested in CI.
   suite (serde, codecs, per-protocol request round trips, real-TCP transport
   round trips incl. Beast and Beast TLS) run in CI.
 
-[0.1.0]: https://github.com/aaylward/smithy-cpp/releases/tag/v0.1.0
+[Unreleased]: https://github.com/aaylward/smithy-cpp/commits/main

MODULE.bazel

@@ -1,3 +1,8 @@
+# The bzlmod module version stays 0.0.0 until the module is published to the
+# Bazel Central Registry (deferred, PLAN Phase 6); consumers override the source
+# with git_override/local_path_override, which ignores this value. The product
+# version consumers actually observe is smithy::Version() / the client
+# User-Agent ("0.1.0-dev"). See docs/versioning.md.
 module(
     name = "smithy_cpp",
     version = "0.0.0",

README.md

@@ -16,7 +16,7 @@ experience assumed. Day 2 (evolving the model) is
 - **Bazel-native:** Bazel 9 is the sole supported build system for the repo and consumers.
 - **Client tests server:** generated clients integration-test generated servers in CI.
 
-## What works today (v0.1.0)
+## What works today (0.1.0-dev, untagged)
 
 - **Clients and servers for all three protocols**, each green against a conformance suite in CI
   (the official alloy and rpcv2Cbor suites, an authored one for jsonRpc2) with documented,

docs/quickstart.md

@@ -50,11 +50,14 @@ module(name = "my_service", version = "0.0.0")
 bazel_dep(name = "smithy_cpp", version = "0.0.0")
 
 # Until smithy_cpp is published to the Bazel Central Registry (deferred until
-# the project is production-validated), consume it by path or git override:
+# the project is production-validated), consume it by git override. No release
+# is tagged yet, so pin a specific commit on main (copy the full SHA from
+# https://github.com/aaylward/smithy-cpp/commits/main). The `version` above is
+# ignored while an override is in effect.
 git_override(
     module_name = "smithy_cpp",
     remote = "https://github.com/aaylward/smithy-cpp.git",
-    commit = "<pin a commit>",
+    commit = "0000000000000000000000000000000000000000",  # replace with a real commit SHA
 )
 
 bazel_dep(name = "googletest", version = "1.17.0.bcr.2")

docs/versioning.md

@@ -5,6 +5,20 @@ release is one git tag (`vX.Y.Z`, signed) covering both, and generated code
 from generator X.Y is supported against runtime X.Y. `smithy::Version()`
 returns the runtime's version.
 
+## Current state: pre-release, untagged
+
+No release is tagged yet. The 0.1.0 milestone is developed on `main`, and the
+one product version consumers observe — `smithy::Version()`
+(`runtime/src/core/version.cc`) and the client `User-Agent`
+(`smithy::ClientConfig::user_agent`) — reports **`0.1.0-dev`** until the first
+signed tag lands. The bzlmod **module** version in `MODULE.bazel` is a separate
+identifier and stays `0.0.0` until the module is published to the Bazel Central
+Registry (deferred, PLAN Phase 6); consumers override the module source with
+`git_override`/`local_path_override`, which ignores that value, so pin a commit
+on `main` (there is no tag to pin). When 0.1.0 is cut, drop the `-dev` suffix,
+move the CHANGELOG's `[Unreleased]` section under `[0.1.0]`, and follow the
+release mechanics below.
+
 ## Semantic versioning
 
 Pre-1.0 caveat (per semver): minor releases may break. Concretely:

runtime/include/smithy/client/config.h

@@ -23,7 +23,9 @@ namespace smithy {
 struct ClientConfig {
   std::string endpoint;
   int request_timeout_ms = 30000;
-  std::string user_agent = "smithy-cpp/0.0.0-dev";
+  // Mirrors smithy::Version() (runtime/src/core/version.cc), the single source
+  // of truth for the product version.
+  std::string user_agent = "smithy-cpp/0.1.0-dev";
 
   // Full-jitter exponential backoff for transport failures and transient
   // statuses (429/5xx); retry.max_attempts = 1 disables retries.

runtime/src/core/version.cc

@@ -2,6 +2,9 @@
 
 namespace smithy {
 
-std::string_view Version() { return "0.1.0"; }
+// Pre-release: the 0.1.0 milestone is developed on main but not yet tagged, so
+// the runtime reports a "-dev" suffix (see docs/versioning.md). This is the one
+// source of truth for the product version; the client User-Agent mirrors it.
+std::string_view Version() { return "0.1.0-dev"; }
 
 }  // namespace smithy

runtime/tests/core/version_test.cc

@@ -7,7 +7,8 @@ namespace {
 
 TEST(VersionTest, ReturnsSemanticVersion) {
   EXPECT_FALSE(Version().empty());
-  EXPECT_EQ(Version(), "0.1.0");
+  // Pre-release until the first signed tag (docs/versioning.md).
+  EXPECT_EQ(Version(), "0.1.0-dev");
 }
 
 }  // namespace