Bump to 6.2.0-alpha1 and start docs/NEXT-RELEASE.md - #3014
Merged
Conversation
Release notes for the version in development live in the repo now, so they are versioned with the change that caused them instead of being reconstructed from the commit log at the end. Every PR that changes something a user can notice adds its entry to docs/NEXT-RELEASE.md in the same commit, the file grows through the alphas, and it is copied into the release body as it is. Filled it with the notes for 6.2.0-alpha1, covering everything since the 6.1.0 tag: the Pester.BeforeContainer.ps1 cascade, the Should-BeString region diff, strict configuration values, error locations, and parallel on Windows PowerShell 5.1. ModuleVersion 6.2.0, Prerelease alpha1, RequiredAssemblyVersion 6.2.0, and the ReleaseNotes URL points at the 6.2.0-alpha1 tag. 🤖
nohwnd
commented
Aug 29, 2026
nohwnd
commented
Aug 29, 2026
nohwnd
commented
Aug 29, 2026
nohwnd
commented
Aug 29, 2026
Drop the "Pester 6 runs on Windows PowerShell 5.1 and PowerShell 7.4+" line, nothing changed there and it reads as if something did. Say the root setup file holds the common setups and teardowns every test needs, it only ever applies to tests. Describe multiple BeforeAll/AfterAll per block as something you can now do, with an example, instead of as an error that stopped happening. Remove the Repository section, CI and the self-test tracer are not something a user of the module has any use for. Also rewrote the maintainer comment at the top to say what the file is actually for: the notes are written once for the first alpha, which is usually close to feature complete, so there is one set to read and approve and every prerelease after it is a small diff. 🤖
nohwnd
added a commit
that referenced
this pull request
Sep 5, 2026
Stacked pull requests target the branch below them, not main, and the branches filter on pull_request meant they got no CI at all. #3015 sat on release-6.2.0-alpha1 and only started running checks when #3014 merged and GitHub retargeted it to main, so while working on it there was no way to tell if the change was correct. The filter never protected anything. With the pull_request trigger a run from a fork gets a read-only token and no secrets no matter what branch it targets, so dropping it does not change what untrusted code can reach. It only ever skipped runs we wanted. Also drop paths-ignore from pull_request in ci.yml. Done is a required check on main and it lives in that workflow, so a run skipped by the filter means Done never reports and the pull request stays blocked with nothing to click. Runners are free for public repos. code-analysis.yml was narrower than ci.yml, it only ran for pull requests onto main, so rel/* and dev/* never got PSScriptAnalyzer either. 🤖
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release notes for the version in development live in the repo now, in
docs/NEXT-RELEASE.md. The idea is that every PR that changes something a user can notice adds its entry there in the same commit, so the notes are versioned next to the change instead of being reconstructed from the commit log at the end. The file grows through the alphas and is copied into the release body as it is, the maintainer block at the top is an HTML comment so it does not render.Filled it with the notes for 6.2.0-alpha1, which is everything since the 6.1.0 tag:
Pester.BeforeContainer.ps1cascade from Apply Pester.BeforeContainer.ps1 from the repo root down to the test file #2993, with a full folder example and the three behavior changes it bringsShould-BeStringregion diff from Show every region that differs when Should-BeString fails on a big string #3010BeforeAllfrom Keep the real error when user code throws, instead of reporting an escaped break #3005Every example in the notes was run against this build, the output blocks are pasted from the real run.
Version:
ModuleVersion6.2.0,Prereleasealpha1,RequiredAssemblyVersion6.2.0, andReleaseNotespoints at the 6.2.0-alpha1 tag. Minor bump because there are features in there, not only fixes.Verification
./build.ps1 -Cleanthen./test.ps1on PS 7.5 macOS: P phase 23 blocks 0 failed, RSpec 2921 passed, 0 failed, 3 skipped.Pester v6.2.0-alpha1in the banner, assembly 6.2.0.0, informational version 6.2.0-alpha1.🤖