Skip to content

Release: finalize the migration guide, test the AI prompt, write the 1.0.0 changelog #159

Description

@tablackburn

Part of #120 (Phase 5 — Release).

Scope

Finalize the consumer-facing release documentation, once the full break surface is known and soaking.

  • docs/migration-v0.8-to-v1.0.md — review end to end. Per-PR entries have been accumulating throughout the cycle by design, so this is a coherence and completeness pass, not a writeup from scratch. Confirm the scope decision holds: breaking changes plus behavioral changes that can require action on upgrade.
  • Test the AI migration prompt. The guide's top-of-file prompt is a v1.0.0 deliverable and has never been exercised. Run it against a real sample consumer build.ps1 with an agent and fix what it gets wrong. An untested prompt that produces a broken build.ps1 is worse than no prompt.
  • CHANGELOG.md — write the 1.0.0 entry, summarizing the breaks and linking to the migration guide.

Gate

Blocked on every other v1.0.0 pull request being merged — the break surface must be complete before the guide can be called finished. Re-gated 2026-09-04: the preview and rc were dropped from the plan, so the gate is now the merge of #224, #225, #226, #227 and #228. This issue must close before 1.0.0 is tagged.

Done when

The migration guide is complete, the AI prompt has been verified against a sample consumer build, and the changelog entry is written.

Activity

  1. added this to the v1.0.0 milestone on Aug 20, 2026
  2. tablackburn commented on Aug 28, 2026

    @tablackburn
    ContributorAuthor

    Unblocked. This is now the only thing between the repository and 1.0.0.

    Its gate read "blocked on 1.0.0-preview2 — the break surface must be complete before the guide can be called finished." That condition is satisfied, but by scope rather than by a release: #83 and #156 are deferred to 1.1.0, so Phase 3 is empty and nothing further is going into 1.0.0 that breaks anything. #157 and #158 are closed as superseded; the cycle cuts one prerelease, the rc1 in #160.

    So the guide can be finished now, and it should be — the prerelease goes out after this, so soakers get finished documentation telling them what changed rather than an unfinished one.

    Current state of the work:

    • docs/migration-v0.8-to-v1.0.md is 747 lines across 12 sections. As this issue anticipated, the per-PR entries accumulated through the cycle, so this is a coherence and completeness pass rather than a writeup.
    • The AI migration prompt has still never been run. That is the substantive item here: it is a v1.0.0 deliverable that rewrites a consumer's build.ps1, and shipping it untested is worse than shipping no prompt at all.
    • The 1.0.0 changelog entry is unwritten. ## Unreleased has accumulated the full break surface and needs summarizing.

    One addition to the completeness pass, since the guide predates them: the cycle picked up several changes after most of those entries were written — the Pester 6.0.0 floor (#172), the psake 5.0.4 floor (#166), Sign.SkipCertificateValidation actually working (#193), and the localized-string fix (#185). Worth checking each has an entry if it can require action on upgrade.

  3. tablackburn commented on Aug 28, 2026

    @tablackburn
    ContributorAuthor

    PR #200 is merged, but this stays open deliberately.

    Done

    Why this is not closed

    The gate on this issue was that the break surface must be complete before the guide can be called finished. That was true this morning. It stopped being true this afternoon, when #98 and #103 came back into the 1.0.0 milestone.

    Those are test-writing tickets, and on this project test-writing has found a defect every single time: #169 (updatable help had never worked — three of them), the Get-PSBuildCertificate mocks that never reached the module, #197 (22 tests silently skipped on 5.1), #201 (found by accident). #98's own scope says to expect more. Any of those fixes that are user-facing need a guide entry, and #201 already looks like one.

    What is left here

    A final coherence pass once #98 and #103 close:

    • Re-check the changelog's ## Unreleased entries against the guide's entries, the same way the first pass did — anything that can require action on upgrade needs an entry.
    • Re-verify the table of contents against the headings.
    • Re-check the 1.0.0 changelog summary's "breaks that require action" table, since it was written against today's surface.

    That is a short pass, not a rewrite. It exists so that #160's "blocked on the release documentation being final" means something.

  4. tablackburn commented on Sep 3, 2026

    @tablackburn
    ContributorAuthor

    Candidates for the coherence pass, not changes to make now — recording them so they are not
    lost while the break surface settles.

    Testing the AI migration prompt against four real public consumer builds turned up three things
    the guide covers nowhere. Each is verified against this repository's source and against the
    consumer's own build file; I have said which parts I confirmed and which I did not.

    1. A consumer task that calls a platyPS 0.14.x cmdlet has nowhere to land

    Confirmed. The guide explains the YamlDotNet clash twice — under the requirements.psd1
    entry and under "Help generation now uses Microsoft.PowerShell.PlatyPS 1.x" — but both times as
    a reason to remove platyPS from a dependency manifest. Neither addresses a consumer whose
    own task body calls a 0.14.x cmdlet. Grepping the guide for New-YamlHelp,
    New-ExternalHelp, New-MarkdownHelp, Update-MarkdownHelp and New-ExternalHelpCab returns
    nothing: no 0.14.x cmdlet is named anywhere in it.

    jimbrig/PSUtils is the concrete case (psakeFile.ps1, lines 39-43):

    Task GenerateYAMLHelp -depends GenerateMarkdown {
        If (-not (Get-Command New-YamlHelp -CommandType Function -ErrorAction SilentlyContinue)) {
            Install-Module -Name platyPS -Repository PSGallery -Scope CurrentUser -Force
        }
        New-YamlHelp -Path './Docs/en-US' -OutputFolder './Docs/en-US' -Force

    The task installs and imports platyPS 0.14.x on demand, into the same session where
    GenerateMarkdown has already imported Microsoft.PowerShell.PlatyPS 1.x — exactly the
    collision the guide warns about, arriving from a direction the guide does not describe.
    Following the requirements.psd1 advice to the letter does not fix it; the task itself has to
    change.

    There is a landing place worth mentioning: 1.x ships Export-YamlCommandHelp and
    Export-YamlModuleFile. Whether the guide should name the replacement or only flag the hazard
    is a coherence-pass call.

    2. An Invoke-Build consumer can override Task Test and lose script analysis

    Confirmed — and narrower than first described: it is an Invoke-Build-only hazard.

    PowerShellBuild/IB.tasks.ps1 line 201 defines:

    Task Test Analyze, Pester

    pauby/PSTodoWarrior's .pstodowarrior.build.ps1 dot-sources PowerShellBuild.IB.Tasks on
    line 2, sets these on lines 26-27:

    $PSBPreference.Test.ScriptAnalysis.Enabled = $true
    $PSBPreference.Test.ScriptAnalysis.FailBuildOnSeverityLevel = 'Error'

    and then, on line 66, defines its own:

    Task Test Pester

    Reproduced against InvokeBuild 5.14.23 with a stand-in tasks file of the same shape: without the
    redefinition Test runs Analyze then Pester; with it, only Pester runs. The build reports
    success and 0 warnings either way. Invoke-Build does print Redefined task 'Test'. in the
    build log, so "silently" is a little too strong — but that is a log line rather than a warning,
    and it does not say that Analyze is what got dropped. Those two ScriptAnalysis settings have
    never taken effect and will not after migrating.

    The asymmetry seems worth the guide's while: psake refuses the same move. psake 5.0.4 throws
    Task test has already been defined. from public/Task.ps1, so a psake consumer finds out
    immediately. Only Invoke-Build consumers can carry this quietly.

    This is not a 1.0.0 break — it is pre-existing, and migrating neither causes it nor fixes it.
    But the migration is the moment a consumer reads their build file closely, which may make it the
    right moment to tell them to check.

    3. A task that rewrites online version: stops matching anything

    Confirmed on both sides, with a caveat: the guide is not silent on the key change, only on the
    consequence.

    The rename is already documented, under "What the front matter becomes" (lines 726-727):
    "schema: becomes PlatyPS schema version:, online version: becomes HelpUri:". I confirmed
    the generated output independently — a document produced by New-MarkdownCommandHelp on 1.0.3
    carries HelpUri: '' and no online version: key at all.

    What is missing is the consequence for a consumer post-processing that front matter.
    milestonesys/MilestonePSTools (psakefile.ps1) wires a task into the pipeline on line 81:

    $psake.context.tasks.GenerateMAML.DependsOn += @('SetOnlineHelpUrls', 'AddCommandRequirementsToDocs')

    and that task matches on the old key, line 283:

    if ($_ -match '^online version:.*$') {

    A regular expression that matches nothing rewrites nothing and reports nothing. The task keeps
    running, keeps succeeding, and the online help URLs quietly stop being set. A reader who reaches
    the front-matter table has the fact they need; a reader who greps their own build file for
    things the guide named does not, because the guide never connects the rename to the
    pattern-matching a consumer may be doing against it.

    Known limitation of the prompt testing itself

    Recording this as a limitation rather than a defect: every run of the prompt test fetched the
    guide with curl, so the guide's own warning — that a summarizing fetch tool drops entries —
    was never exercised. An agent without shell access, which is precisely the case the warning is
    written for, remains untested.

    Relatedly, the claim on lines 150-151 that "We measured three entries lost that way in testing"
    was not re-verified by this work. It may well still hold; it is simply not among the things I
    checked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    wayfinder:taskWayfinder ticket: manual work that unblocks a decision

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions