release(psmodule): finish Visio.psd1 deprecation cleanup (closes #178)

VisioAutomation_2010/VisioPowerShell/CHANGELOG.md

@@ -15,6 +15,7 @@ The format follows [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/
 ### Changed
 - Module manifest's `Author` and `Copyright` fields updated from `Saveen Reddy` to `SevenPens` to reflect the new dev-team identity. No functional change; the displayed-author string on the [PSGallery package page](https://www.powershellgallery.com/packages/Visio) updates on the next release. Legal copyright record (LICENSE.txt) updated correspondingly.
 - Module is now built and published as **Release** instead of Debug. The published `.zip` and PSGallery package contain optimized binaries with no `[Debuggable]` attribute and no `.pdb` symbol files. No source-level behavior change (the C# source has no `#if DEBUG` blocks) but assemblies are smaller and JIT optimizations are no longer suppressed. Closes [#177](https://github.com/saveenr/VisioAutomation/issues/177).
+- Module manifest cleanup: `ModuleToProcess = 'VisioPS.dll'` switched to `RootModule = 'VisioPS.dll'` (the deprecated `ModuleToProcess` member was emitting `Publish-Module` warnings on every PSGallery upload), and `PowerShellVersion = '2.0'` bumped to `'5.1'` to match what the binary cmdlets actually require (compiled against `Microsoft.PowerShell.3.ReferenceAssemblies`, never loadable on PS < 3.0; PSGallery and `Publish-VisioPSToGallery.ps1` already gate at PS 5.1). Removed the now-vestigial `CLRVersion = '4.0'` declaration; the shipping libs target .NET Framework 4.5.2 and PS 5.1 already implies CLR 4.0+. **Customer impact: zero** — aligns the manifest's declarations with what the module actually requires; no extant user becomes unable to run it. Closes [#178](https://github.com/saveenr/VisioAutomation/issues/178).
 
 ## [4.7.2] - 2026-05-06
 

VisioAutomation_2010/VisioPowerShell/Visio.psd1

@@ -4,8 +4,7 @@
 @{
 
 # Script module or binary module file associated with this manifest.
-# RootModule = 'VisioPS.dll' - Commented this out because having RootModule defined causes the module to fail to load with PowerShell 2.0
-ModuleToProcess = 'VisioPS.dll' # Use ModuleToProcess instead of RootModule because it works for both PowerShell 2.0 and 3.0
+RootModule = 'VisioPS.dll'
 
 # Version number of this module.
 ModuleVersion = '4.7.2'
@@ -26,7 +25,7 @@ Copyright = 'SevenPens'
 Description = 'Visio PowerShell - Automation cmdlets for Visio version 2010 and above'
 
 # Minimum version of the Windows PowerShell engine required by this module
-PowerShellVersion = '2.0'
+PowerShellVersion = '5.1'
 
 # Name of the Windows PowerShell host required by this module
 # PowerShellHostName = ''
@@ -38,7 +37,7 @@ PowerShellVersion = '2.0'
 # DotNetFrameworkVersion = ''
 
 # Minimum version of the common language runtime (CLR) required by this module
-CLRVersion = '4.0'
+# CLRVersion = ''
 
 # Processor architecture (None, X86, Amd64) required by this module
 # ProcessorArchitecture = ''

docs/COMPLETED.md

@@ -83,6 +83,10 @@ Headline summary in [`ROADMAP.md`](ROADMAP.md#phase-3--modernization-in-progress
 - **What:** PSGallery publish was a manual local-machine flow via [`Publish-VisioPSToGallery.ps1`](../VisioAutomation_2010/VisioPowerShell/Publish-VisioPSToGallery.ps1) with the API key on the developer's workstation. Goal: shift to a CI publish that takes the GitHub Release artifact (already produced by [`release-psmodule.yml`](../.github/workflows/release-psmodule.yml)) and uploads it to PSGallery, so the binary on PSGallery is exactly the one humans inspected on the GH Release, and the API key lives only as a GitHub Actions secret. Stated more concretely as a futures item after the manual 4.7.0 publish surfaced the local-machine friction (Smart App Control transient blocks, "use a fresh PowerShell session" caveat, API-key-on-workstation footprint).
 - **Resolution:** New [`.github/workflows/publish-psmodule.yml`](../.github/workflows/publish-psmodule.yml). `workflow_dispatch`-triggered, takes the release tag as input, downloads the `Visio-<version>.zip` artifact from the GH Release via `gh release download`, extracts it, verifies the staged `ModuleVersion` matches the tag, runs a `CmdletsToExport` drift check (loads the module and compares declared cmdlets vs the binary's `ExportedCmdlets`), forces TLS 1.2, runs `Publish-Module`, then verifies the upload via `Find-Module` with retry. Has a `dry_run` input that exercises every step except the actual upload &mdash; lets the workflow be tested against the existing 4.7.0 GH Release without touching PSGallery, since gallery versions are immutable. Companion change: `Publish-VisioPSToGallery.ps1`'s tag step refactored to be idempotent (skips silently if the tag already exists at HEAD; throws if the tag exists but points elsewhere) so the local script and the workflow can coexist for fallback / out-of-band publishes. The `CmdletsToExport='*'` &rarr; explicit-list change in `bd627062` is the prereq that made the drift check possible. Setup required: `PSGALLERY_API_KEY` repository secret (one-time, mentioned in the workflow file's header comment).
 
+#### Address `Visio.psd1` deprecation warnings on PSGallery publish
+- **What:** Two final pieces of the long-running [`Visio.psd1`](../VisioAutomation_2010/VisioPowerShell/Visio.psd1) cleanup that started 2026-05. The `CmdletsToExport` half had landed earlier (manifest now lists 64 cmdlets explicitly so the publish-time best-practice warning is silent). Still pending: the `ModuleToProcess` &rarr; `RootModule` rename and the `PowerShellVersion` bump. Each 4.7.x publish to PSGallery had been emitting `The module manifest member 'ModuleToProcess' has been deprecated. Use the 'RootModule' member instead.` (twice per upload).
+- **Resolution (closes [#178](https://github.com/saveenr/VisioAutomation/issues/178)):** Three one-line edits in [`Visio.psd1`](../VisioAutomation_2010/VisioPowerShell/Visio.psd1): (1) `ModuleToProcess = 'VisioPS.dll'` &rarr; `RootModule = 'VisioPS.dll'` (the historical comment about needing `ModuleToProcess` for PS 2.0 / 3.0 compat is moot; the binary cmdlets are compiled against `Microsoft.PowerShell.3.ReferenceAssemblies` and have never been loadable on PS 2.0); (2) `PowerShellVersion = '2.0'` &rarr; `'5.1'` to match what PSGallery's `Install-Module` and the local `Publish-VisioPSToGallery.ps1` already require; (3) the now-vestigial `CLRVersion = '4.0'` declaration removed (PS 5.1 already implies CLR 4.0+; the shipping libs target .NET Framework 4.5.2, not 4.0). **Customer impact: zero** &mdash; the bumped declarations align with what the module actually requires; no extant user becomes unable to run it (PS 5.1 is the de facto floor today via Windows 10 1607+ / LTSB 2016 / Win 11 / Server 2016+; pre-5.1 installs were already blocked by the binary cmdlets and the publish path).
+
 ### Code & architecture
 
 #### PowerShell cmdlet positional-parameter UX audit

docs/futures/releases.md

@@ -22,39 +22,6 @@ Backlog of items related to release process, version policy, and publishing to p
 - **Cross-refs:** *Automate releases via GitHub CI* below — the CI workflow either flips the constant or stages the release config separately.
 - **Effort:** S.
 
-### Address `Visio.psd1` deprecation warnings on PSGallery publish
-- **Status (2026-05-06):** the `CmdletsToExport` half landed (manifest now lists 64 cmdlets explicitly; the publish-time best-practice warning will be silent on the next release). The `ModuleToProcess` → `RootModule` rename and `PowerShellVersion` bump are still pending; deferred deliberately, not blocked. Customer-impact analysis below.
-- **What's left:** The 4.7.0 publish to PSGallery (2026-05-06) emitted these still-active warnings from `Publish-Module`:
-  - `The module manifest member 'ModuleToProcess' has been deprecated. Use the 'RootModule' member instead.` (fires twice — once during local staging, once on the gallery upload).
-- **Why the warning fires:** [`Visio.psd1`](../../VisioAutomation_2010/VisioPowerShell/Visio.psd1) line 8 sets `ModuleToProcess = 'VisioPS.dll'` with an inline comment ("Use ModuleToProcess instead of RootModule because it works for both PowerShell 2.0 and 3.0") and the manifest declares `PowerShellVersion = '2.0'`. The compatibility target is essentially dead: PS 2.0 was removed from Windows 11; PSGallery's `Install-Module` requires PS 5.1+; [`Publish-VisioPSToGallery.ps1`](../../VisioAutomation_2010/VisioPowerShell/Publish-VisioPSToGallery.ps1) itself refuses to run below PS 5.1.
-- **How to apply when picked up:**
-  - Switch `ModuleToProcess` to `RootModule` in [`Visio.psd1`](../../VisioAutomation_2010/VisioPowerShell/Visio.psd1) (toggle the comment on lines 7-8). Bump `PowerShellVersion = '2.0'` to `'5.1'` to match the publish script's own minimum check. Optionally drop `CLRVersion = '4.0'` (paired with .NET Framework 4.0; the shipping libs target 4.5.2).
-
-#### Customer impact of the `PowerShellVersion = '2.0'` → `'5.1'` bump
-
-(Pre-derived 2026-05-06 so it doesn't have to be reasoned through again when this is picked up.)
-
-| PS version | Ships with | Status | Impact of bump |
-|---|---|---|---|
-| 7.x | separate install, cross-platform | current | unaffected (7 satisfies the `>= 5.1` floor) |
-| 5.1 | Windows 10 1607+ (2016), Win 11, Server 2016+ | current | **unaffected** — this is the de facto floor today |
-| 5.0 | Windows 10 1507/1511 only (2015-2016) | unsupported Windows | newly blocked, but Windows itself is end-of-life |
-| 4.0 | Windows 8.1, Server 2012 R2 | OOS since 2023 | newly blocked, but unlikely to be a VisioPS user |
-| 3.0 | Windows 8 | OOS since 2023 | same |
-| 2.0 | Windows 7 | OOS since 2020 | already broken — the binary cmdlets are compiled against `Microsoft.PowerShell.3.ReferenceAssemblies` and won't load on PS 2.0 regardless of what the manifest claims |
-
-Effective customer impact: **zero**. The current `PowerShellVersion = '2.0'` is aspirational, not real; the binary already won't run on anything below PS 3.0, and the entire installation path (PSGallery + `Publish-VisioPSToGallery.ps1`) gates at 5.1. Bumping the manifest aligns the declaration with what the module actually requires; no extant user becomes unable to run it. LTSB 2016 (the ongoing compat constraint until 2026-10-13) ships with PS 5.1, so the bump does not affect those users either.
-
-#### Maintenance note on `CmdletsToExport`
-The list now has 64 entries. Adding a new cmdlet requires also adding it to the manifest. Two options to enforce when convenient:
-- (a) Manual reminder in cmdlet-author docs / `CONTRIBUTING.md`.
-- (b) Pre-publish check that loads the staged module, diffs `Get-Module -Name Visio | Select-Object -ExpandProperty ExportedCmdlets` against the manifest's `CmdletsToExport`, and fails if they differ. Drop into `Publish-VisioPSToGallery.ps1` between the staging step and the `Publish-Module` call.
-
-Option (b) is a few lines of PowerShell; worth adding when the *PSGallery publish via "release first..."* item below lands, since that's the natural place to put the check.
-
-- **Cross-refs:** *Automate releases via GitHub CI* below — the publish workflow should also surface these warnings as a CI signal so future drift is caught early.
-- **Effort to finish:** S. Single commit, no behavior change for any extant user. The `RootModule` swap is one line; the `PowerShellVersion` bump is one line.
-
 ### Automate releases via GitHub CI *(in progress)*
 - **What:** Replace the current manual release process with GitHub Actions workflows that handle **three deliverables** end-to-end:
   1. **PSGallery publish** of the `Visio` PowerShell module — ✅ landed, see below.