Skip to content

[PM-39513] chore: Pin library project versions to 0.0.1 - #8238

Open
justindbaur wants to merge 1 commit into
mainfrom
pin-library-versions
Open

[PM-39513] chore: Pin library project versions to 0.0.1#8238
justindbaur wants to merge 1 commit into
mainfrom
pin-library-versions

Conversation

@justindbaur

@justindbaur justindbaur commented Aug 20, 2026

Copy link
Copy Markdown
Member

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-39513

Follow-up to the churn seen in #8179 (Bump version to 2026.8.0).

📔 Objective

Every project's <Version> is recorded in each consumer's packages.lock.json, so bumping
<Version> in the root Directory.Build.props rewrites ~60 of the 77 lock files on every
release. This pins projects that are only ever consumed as libraries to 0.0.1 so those
entries stop moving, extending the pattern already established in
src/Libraries/Directory.Build.props to the libraries living outside that folder.

15 projects pinned

  • src/: Core, HttpExtensions, Infrastructure.Dapper, Infrastructure.EntityFramework, SharedWeb, Pam.Domain
  • bitwarden_license/src/: Commercial.Core, Commercial.Infrastructure.EntityFramework
  • util/: Migrator, MySqlMigrations, PostgresMigrations, SqliteMigrations, RustSdk, Seeder
  • test/: Common

Impact

Measured by pointing Directory.Build.props at a throwaway next version and running
dotnet restore --force-evaluate:

lock files touched by a version bump
before 60 / 77
after 11 / 77

Pam.Domain was the single biggest contributor — unpinned, it alone accounted for 40 files,
because both Infrastructure.Dapper and Infrastructure.EntityFramework reference it and it
therefore leaks into nearly every closure.

The remaining 11 are integration-test projects that legitimately reference Identity, Api,
or Pam. That is the floor without pinning the deployable services themselves.

Why this is safe

Nothing reports these assemblies' versions. MapVersionEndpoint() resolves
IBitwardenEnvironment.Version, which reads the entry assembly's
AssemblyInformationalVersionAttribute — and every deployable service (Api, Identity, Admin,
Events, EventsProcessor, Icons, Notifications, Billing, Sso, Scim, SeederApi, Pam) is left
unpinned. Admin's self-hosted "installed version" panel uses the same accessor. None of these
projects are packed or pushed to a feed, and none are strong-named.

Note on test/Migrator.Test/packages.lock.json

This is the one lock file whose diff is not purely the version pin. It was committed stale in
#8143 (added 2026-08-17, a week after the 2026-08-10 bump) and still referenced 2026.7.2
plus older Microsoft.Extensions.* patch versions. --force-evaluate corrected it. The other
59 lock files contain version-pin changes only.

📸 Screenshots

N/A — build configuration only.

@justindbaur
chore: Pin library project versions to 0.0.1
2205637 
Every project's <Version> is recorded in each consumer's packages.lock.json,
so bumping <Version> in the root Directory.Build.props rewrote ~60 of the 77
lock files on every release (see #8179). Pinning projects that are only ever
consumed as libraries keeps those entries stable.

This extends the pattern already established in src/Libraries/Directory.Build.props
to the libraries that live outside that folder.

Safe because nothing reports these assemblies' versions. MapVersionEndpoint()
resolves IBitwardenEnvironment.Version, which reads the *entry* assembly's
AssemblyInformationalVersionAttribute -- and the deployable services (Api,
Identity, Admin, Events, EventsProcessor, Icons, Notifications, Billing, Sso,
Scim, SeederApi, Pam) are all left unpinned. Admin's self-host "installed
version" panel uses the same accessor. None of these projects are packed or
pushed to a feed, and none are strong-named.

Measured by setting Directory.Build.props to a throwaway next version and
running `dotnet restore --force-evaluate`: the next version bump now touches
11 lock files instead of 60. The remainder are integration-test projects that
reference Identity, Api, or Pam.

Note: test/Migrator.Test/packages.lock.json contains more than the version
pin. It was committed stale in #8143 (added 2026-08-17, a week after the
2026-08-10 bump) and still referenced 2026.7.2 plus older Microsoft.Extensions
patch versions; --force-evaluate corrected it. The other 59 lock files contain
version-pin changes only.
@justindbaur justindbaur added the ai-review Request a Claude code review label Aug 20, 2026
@github-actions

github-actions Bot commented Aug 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the addition of <Version>0.0.1</Version> to 15 library-only projects across src/, bitwarden_license/src/, util/, and test/, plus the 60 regenerated packages.lock.json files. Verified that no source file in the repo reads an assembly version (IBitwardenEnvironment.Version is the only version surface, consumed by ConfigResponseModel and Admin's HomeController, and every deployable entry point remains unpinned), that no project is packed or strong-named, and that repository-management.yml only rewrites the root Directory.Build.props. Confirmed no packages.lock.json anywhere in the tree still records a pinned project at a non-0.0.1 range, and that the 11 files still carrying 2026.8.0 reference only the unpinned Identity, Api, Pam, and IntegrationTestCommon projects — matching the PR's stated floor. All 40 CI checks pass, including every Docker build and the locked-mode restore they perform.

Code Review Details

No findings.

Notes for the reviewer (not findings):

  • Per-file --numstat shows every lock file is a 1:1 line swap except test/Migrator.Test/packages.lock.json (119/113), matching the PR's stale-lock explanation. Its corrections bring it in line with the rest of the tree: Microsoft.Extensions.* 10.0.8/10.0.9 → 10.0.10 and Stripe.net → 52.1.0, which now matches test/Core.Test/packages.lock.json.
  • src/HttpExtensions, src/Pam.Domain, and util/RustSdk correctly have no lock file change of their own — a project's own version is never recorded in its own lock file, only in consumers' dependency ranges.
  • test/IntegrationTestCommon is still unpinned and appears at [2026.8.0, ) in two consumers, but pinning it would not reduce churn since those same files already reference Api/Identity directly.

@codecov

codecov Bot commented Aug 20, 2026 •
edited
Loading

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.57%. Comparing base (fc5ea9a) to head (2205637).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files 
@@            Coverage Diff             @@
##             main    #8238      +/-   ##
==========================================
+ Coverage   63.28%   68.57%   +5.28%     
==========================================
  Files        2401     2401              
  Lines      104003   104043      +40     
  Branches     9417     9426       +9     
==========================================
+ Hits        65817    71344    +5527     
+ Misses      35930    30341    -5589     
- Partials     2256     2358     +102

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@justindbaur justindbaur added the t:tech-debt Change Type - Tech debt label Aug 21, 2026
@justindbaur
justindbaur marked this pull request as ready for review August 21, 2026 13:25
@justindbaur
justindbaur requested review from a team as code owners August 21, 2026 13:25
@justindbaur
justindbaur requested a review from djsmith85 August 21, 2026 13:25
withinfocus
withinfocus approved these changes Aug 21, 2026
View reviewed changes

@withinfocus withinfocus left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As already discussed.

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

Reviewers

@withinfocus withinfocus withinfocus approved these changes
@dereknance dereknance dereknance approved these changes
@djsmith85 djsmith85 Awaiting requested review from djsmith85 djsmith85 is a code owner automatically assigned from bitwarden/team-platform-dev

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

ai-review Request a Claude code review t:tech-debt Change Type - Tech debt

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@justindbaur @withinfocus @dereknance