PlatyPS 2f: remove the old platyPS 0.14.2 dependency #153

Activity

1. tablackburn

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

   added

   enhancementNew feature or requestNew feature or request

   wayfinder:taskWayfinder ticket: manual work that unblocks a decisionWayfinder ticket: manual work that unblocks a decision

   on Aug 20, 2026
3. tablackburn

   added a parent issue on Aug 20, 2026

   • Update PlatyPS dependency from platyPS v0.14.x to Microsoft.PowerShell.PlatyPS v1.x #105
4. tablackburn

   marked this as blocked by 4 issues on Aug 20, 2026

   • PlatyPS 2b: migrate Build-PSBuildMarkdown to New-MarkdownCommandHelp #150
   • PlatyPS 2c: migrate Build-PSBuildMAMLHelp to Export-MamlCommandHelp #151
   • PlatyPS 2d: migrate Build-PSBuildUpdatableHelp to the 1.x cab pipeline #152
   • PlatyPS 2e: document the docs/ schema conversion for consumers #154
5. tablackburn

   marked this as blocking on Aug 20, 2026

   • Release gate: cut 1.0.0-preview1 after Phase 2 #157
6. tablackburn

   unmarked this as blocked on Aug 24, 2026

   • PlatyPS 2e: document the docs/ schema conversion for consumers #154
7. tablackburn

   unmarked this as blocking on Aug 24, 2026

   • Release gate: cut 1.0.0-preview1 after Phase 2 #157
8. tablackburn commented on Aug 24, 2026

   

   tablackburn

   on Aug 24, 2026

   ContributorAuthor

   More actions

   Folded into the migration itself. Closing — not done, but no longer an independent route
   step.

   This ticket assumed the old dependency lingers through the chain and gets removed at the end.
   That followed from #149's original premise, that the two modules coexist while the three
   functions migrate one at a time. Neither half holds:

   • platyPS 0.14.2 and Microsoft.PowerShell.PlatyPS 1.x each load their own YamlDotNet.dll
     through NestedModules with different assembly identities, so whichever imports second fails
     with "Assembly with same name is already loaded" — in either order, on PowerShell 7.
   • 2b changes the on-disk markdown schema that an unmigrated Build-PSBuildMAMLHelp would be
     handed, so a half-migrated state is broken regardless of the loader.

   The three function migrations are therefore atomic, and with an atomic migration there is never
   a window in which both modules are installed-and-needed. The dependency lives in exactly three
   places:

   • requirements.psd1 — platyPS = '0.14.2'
   • PowerShellBuild.psd1 RequiredModules — platyPS, 0.14.1 (consumer-facing; this is the
     breaking change that needs the migration-guide entry)
   • six Get-Module platyPS -ListAvailable PreConditions across psakeFile.ps1 and
     IB.tasks.ps1

   All of them flip in one commit. "Remove the old dependency" is not a step that follows the
   migration — it is the migration's dependency swap.

   Where that commit sits depends on the still-open route call between one combined pull request
   and a stacked integration branch
   (options). Under
   the combined option it is part of that single pull request. Under the stacked option it is the
   first commit on the integration branch, since CI there needs 1.x installed from 2b onward.
   Either way it is not a separate route ticket, which is why this closes rather than being
   re-scoped.

   Carried forward, so nothing is lost:

   • The RequiredModules swap is a breaking change and needs an entry in
     docs/migration-v0.8-to-v1.0.md. That obligation now rides with the migration pull request.
   • Consumers who commit a docs/ tree need conversion guidance — that is PlatyPS 2e: document the docs/ schema conversion for consumers #154, which no longer
     depends on this ticket.

   Reopen if the route call lands somewhere that makes a standalone removal step meaningful again.
9. tablackburn

   closed this as not plannedon Aug 24, 2026