Skip to content

Carries the upgrading page to 0.42.1 - #689

Merged
johnnyt merged 1 commit into
mainfrom
sb-vd6t-upgrading-page-to-0-42-1
Oct 8, 2026
Merged

johnnyt merged 1 commit into
mainfrom
sb-vd6t-upgrading-page-to-0-42-1

Conversation

@johnnyt

@johnnyt johnnyt commented Oct 8, 2026

Copy link
Copy Markdown
Member

Carries docs/upgrading.md from 0.42 to 0.42.1, with the one thing an upgrade host walking 0.35.0 to 0.42.1 had to change that the page did not say. Only docs/upgrading.md changes.

What changes on the page

  • The title and the opening sentence take the range to 0.42.1.
  • A standing paragraph under the pin advice: the compiler version moves at every release, a patch included. StatifierBlocks.Compiler.compiler_version/0 answers the package's version and the StatifierBlocks.CompilationRecord in what Compiler.compile/3 answers carries it as compiler_version, so a host test that pins it, or compares it with a stored record, moves its literal with each pin. It is said once, at the top, because it applies to every section.
  • "0.41 to 0.42" gains the 0.42.1 patch line, in the shape the page already uses for 0.35.1 and 0.36.1: documentation only, NONE beyond that compiler version.

No other section is touched; the 0.38 pre-flight and the 0.39 note rollout bullets stand as written.

Evidence

The upgrade host in statifier_examples (its PR 191) moved statifier_blocks one minor per commit from 0.35.0 to 0.42.1. Its one forced edit outside mix.exs and mix.lock was a test match on the compile record's compiler_version, moved at every commit, which that PR classes as intended but undocumented. Its palette pre-flight answered [] at 0.38.0 and at 0.42.1 for a palette whose block types are StatifierBlocks.InvokeStep types declared with fields: (each field :string) plus one hand-written type, and its stored document carries no note, so the 0.38 and 0.39 bullets needed no change for it.

Direction check

Every claim on the new lines was read against the tags. compiler.ex at v0.42.1: @compiler_version "0.42.1", compiler_version/0 documented as "this package's version", and the record built with compiler_version: @compiler_version; compiled.ex carries the record as record. At each tag v0.35.0, v0.35.1, v0.36.0, v0.36.1, v0.37.0, v0.38.0, v0.39.0, v0.40.0, v0.41.0, v0.42.0 and v0.42.1, @compiler_version equals that tag's version, and compiler_test.exs's "compiler_version is this package's version" asserts it against mix.exs. The 0.42.1 CHANGELOG entry says it changes documentation only; the lib diff from v0.42.0 to v0.42.1 is that version string, two comment and moduledoc edits, and one private lookup in the editor rewritten to an equivalent helper (block_by_id/2, the same Document.blocks/1 find). InvokeStep's config_schema/1 is built from its fields:, so the 0.38 bullet's declared field types already cover such types. The diff removes two lines, the title and the opening sentence's version, both replaced.

Gate

Full mix quality green on this commit's tree: Format, Compile, Doc links, Dependencies, ADR cites, Docs, Credo, Dialyzer, and Tests (3,954 of 3,954, 95.3% coverage). Doctor, Gettext and Sobelow skip as not installed, as the repo configures. No changelog fragment: the repo's changelog.d/README.md excludes documentation.

The page's range moves from 0.42 to 0.42.1. A standing paragraph under
the pin advice says what moves at every release, a patch included: the
compiler version, which Compiler.compiler_version/0 answers as the
package's version and every CompilationRecord carries, so a host test
that pins it moves its literal with each pin. The upgrade host in
statifier_examples met exactly that at each step from 0.35.0 to 0.42.1
(its PR 191), and the page did not say it.

"0.41 to 0.42" gains the 0.42.1 patch line: documentation only, NONE
beyond that compiler version.
@johnnyt
johnnyt merged commit 861e8ce into main Oct 8, 2026
2 checks passed
@johnnyt
johnnyt deleted the sb-vd6t-upgrading-page-to-0-42-1 branch October 8, 2026 06:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant