Conversation
thomhurst
added
dependencies
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review: Renovate dependency bump (TUnit 1.25.0 → 1.27.0)
This is a straightforward Renovate-generated version bump. The mechanical changes are correct, but there are a few observations worth noting.
What looks good
- All seven packages (
TUnit,TUnit.AspNetCore,TUnit.Assertions,TUnit.Assertions.FSharp,TUnit.Core,TUnit.Engine,TUnit.Playwright) are bumped consistently to1.27.0. - The central version pin in
Directory.Packages.propsis updated alongside the template project files, which is correct.
Inconsistencies / things to be aware of
1. Template version strategy is not uniform
After this PR, the template files have three different version pinning strategies:
| Template | Version |
|---|---|
TUnit/TestProject.csproj |
Version="1.*" (floating minor) |
TUnit.AspNet, TUnit.AspNet.FSharp, TUnit.FSharp, TUnit.Playwright, TUnit.VB |
Version="1.27.0" (hard-pinned) |
TUnit.Aspire.Starter, TUnit.Aspire.Test |
Version="1.14.0" (stale — not touched by this PR) |
The TUnit/TestProject.csproj using 1.* means users who dotnet new tunit get the latest minor automatically without needing these bumps. The other templates are hard-pinned and require manual/Renovate updates every release. Deciding on one approach and applying it consistently would reduce churn. If 1.* is the intended pattern for templates, the others should follow suit.
2. TUnit.Aspire templates appear stale
TUnit.Aspire.Starter and TUnit.Aspire.Test still reference TUnit.Aspire at 1.14.0, which is significantly behind. These are not part of this PR's scope (since Renovate only targeted what was in Directory.Packages.props and the specific project files), but it is worth tracking separately.
3. Hard-pinned versions in templates generate repeated noise
Because templates embed exact versions, every minor TUnit release produces a follow-up Renovate PR touching six or more template files. Using a floating 1.* range (consistent with the base TUnit/TestProject.csproj template) would eliminate this class of PR entirely for template content.
Summary
The bump itself is safe and correct. The main design note is the inconsistency between 1.* in the default template vs. hard-pinned versions in the language/framework-specific templates — converging on one strategy would reduce ongoing maintenance overhead.
There was a problem hiding this comment.
Renovate bump review: Changes are mechanically correct. One consistency note: template files now have three version strategies — floating (1.) in TUnit/TestProject.csproj, hard-pinned (1.27.0) in the other six templates, and stale (1.14.0) for TUnit.Aspire templates not touched by this PR. Converging all templates on the floating 1. pattern (matching the base template) would eliminate this class of Renovate PR in future.
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
TIP This summary will be updated as you push new changes. Give us feedback
thomhurst
force-pushed
the
renovate/tunit
branch
from
3b2afd0 to
4b2f428
Compare
There was a problem hiding this comment.
Follow-up review: TUnit 1.25.0 → 1.27.0 bump
The mechanical changes in this PR remain correct — all seven packages are bumped consistently to 1.27.0.
A previous review (posted on the same commit) raised three observations. None of them have been addressed since the PR has not changed, so they still apply:
Open issues from prior review
1. Inconsistent version strategies across templates
| Template | Version strategy |
|---|---|
TUnit/TestProject.csproj |
1.* (floating minor) |
TUnit.AspNet, TUnit.AspNet.FSharp, TUnit.FSharp, TUnit.Playwright, TUnit.VB |
1.27.0 (hard-pinned) |
TUnit.Aspire.Starter, TUnit.Aspire.Test |
1.14.0 (stale, out of scope for this PR) |
The root template (TUnit/TestProject.csproj) already uses 1.*, which means users get the latest minor automatically and Renovate does not need to touch it on every release. The other templates produce a new Renovate PR every minor bump. Converging them to 1.* would eliminate this class of churn entirely.
2. TUnit.Aspire templates are significantly stale
Both Aspire templates still reference TUnit.Aspire at 1.14.0 (current is 1.27.0). This is not Renovate's fault — TUnit.Aspire is not tracked in Directory.Packages.props. This should either be added to Renovate tracking or migrated to a floating range.
3. Why this matters architecturally
Template project files are not compiled or validated by CI in the same way as source projects. Stale pinned versions in templates mean users who instantiate templates from the NuGet package months from now will get outdated dependencies. A floating minor range (1.*) in template files is idiomatic for templates and avoids this problem without introducing breaking-change risk (since major version is still pinned).
Conclusion
The bump is safe to merge as-is. The above observations are pre-existing design issues rather than regressions introduced by this PR, and would ideally be addressed in a follow-up.
thomhurst
had a problem deploying
to
Pull Requests
GitHub Actions
Failure
2 participants
This PR contains the following updates:
1.25.0→1.27.01.25.0→1.27.01.25.0→1.27.01.25.0→1.27.01.25.0→1.27.01.25.0→1.27.01.25.0→1.27.0Release Notes
thomhurst/TUnit (TUnit)
v1.27.0: 1.27.0What's Changed
Other Changes
Dependencies
Full Changelog: v1.25.0...v1.27.0
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR has been generated by Renovate Bot.