Skip to content

docs(releasing): document constraint-floor bump + packages.lock refresh #31

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
nxships merged 1 commit into from
May 25, 2026
Merged

docs(releasing): document constraint-floor bump + packages.lock refresh #31

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions RELEASING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,10 +4,11 @@ PlayerNexusTracker is a Dalamud plugin and uses tag-driven releases. Unlike the

## Cutting a release

1. **Make sure upstream deps are at the version you expect**. If the Plugin needs new NexusKit or NexusKit.Modules features:
1. **Make sure upstream deps are at the version you expect, and bump the constraint floor**. If the Plugin needs new NexusKit or NexusKit.Modules features:
- NexusKit released first (NexusKit's [RELEASING.md](https://github.com/NexusFFXIV/NexusKit/blob/main/RELEASING.md))
- NexusKit.Modules released next (NexusKit.Modules' [RELEASING.md](https://github.com/NexusFFXIV/NexusKit.Modules/blob/main/RELEASING.md))
- Then bump this repo's `PackageReference` constraints if not already covered by floating versions
- **Bump the constraint floor in `PlayerNexusTracker.Plugin.csproj`** for every `PackageReference` that should pick up a new version, e.g. `[0.1.0,)` → `[0.1.1,)`. NuGet's `PackageReference` resolves to the **lowest** version satisfying the range, so without raising the floor the build will keep resolving the old release even after a new one is on the feed. Verifiable in CI under "List outdated NuGet dependencies" — if Resolved < Latest for any NexusKit package, the floor still needs bumping.
- **Refresh `packages.lock.json`** for the bumped PackageReferences. Locally the sibling-clone swap in `Directory.Build.targets` rewrites NexusKit refs to ProjectReferences and the lock file drops their NuGet entries — that is fine, CI doesn't have the sibling clones and re-evaluates from the csproj on every restore. You can verify by deleting the lock file and running `dotnet restore --force-evaluate` on a clean checkout (or simply rely on CI to surface a mismatch).

2. **Verify `main` is green**:
```powershell
Expand Down Expand Up @@ -67,6 +68,8 @@ Make sure the same fix lands on `main` so v0.3.0 doesn't regress.

## Pre-release versions (testing builds)

**Same constraint-floor + lock-file discipline applies as for stable releases.** If the testing build is meant to pick up an upstream lib update (e.g. a fresh NexusKit.Modules patch), step 1 of "Cutting a release" still has to happen first — otherwise the testing zip ships with the same old NuGets as the previous stable tag and the change you wanted to test is missing.

Tag with a suffix containing `-` to publish a testing build instead of a stable release:

```powershell
Expand Down