Releasing Reactiveproperty

Releasing ReactiveProperty

Run the tag-driven release procedure for the ReactiveProperty NuGet package set.

Prerequisites

• Repository access: permission to push tags to runceel/ReactiveProperty.
• GitHub CLI: authenticated with access to Actions and Releases (gh auth status).
• NuGet trusted publishing: .github/workflows/build-and-publish.yml uses NuGet/login@v1 and secrets.NUGET_USER; if this setup is broken or missing, use the nuget-trusted-publishing skill instead.
• Local validation environment: Windows with the .NET 10 SDK (10.0.x) when running the full solution locally.

Critical Rules

• Ask for release mode first when it is not specified. Use ask_user with choices for pre-release and stable release before doing any release work.
• Never infer the target version from a single tag, release, or the repository <Version> property. If the maintainer has not explicitly supplied the target version, ask for it and stop.
• Always distinguish version sources before confirming a release. Report the newest tag, the newest GitHub Release by publication date, and the newest stable GitHub Release separately; do not call any one of them simply "the latest version".
• The current release workflow is tag-driven. Do not update Source/Directory.Build.props or create a version bump PR unless the maintainer explicitly asks for repository version record-keeping.
• The tag is the package version source of truth. .github/workflows/build-and-publish.yml rewrites Source/Directory.Build.props from the pushed v* tag inside the runner before build/test/package.
• Never overwrite or recreate a release tag. If v{version} already exists locally or remotely, stop and ask the maintainer.
• Never publish manually as a fallback. If OIDC/NuGet publish fails, diagnose the workflow; do not bypass it with a local dotnet nuget push or a long-lived API key.

Release Modes and Version Rules

Normalize a requested version by removing one leading v for validation, then add v back for the tag.

If the user supplies a version that does not match the selected mode, stop and ask for a corrected version.

Package Set

The normal ReactiveProperty.slnx release publishes these package IDs:

ReactiveProperty.UWP is legacy and is not part of the normal ReactiveProperty.slnx release.

Workflow

1. Resolve mode, version, and tag

1. Determine whether this is a pre-release or stable release.
   • If unspecified, call ask_user before proceeding.
2. Determine the target version.
   • Accept only a version explicitly supplied by the maintainer.
   • If unspecified, call ask_user and stop; do not propose or infer a version from tags, releases, package metadata, or Source/Directory.Build.props.
3. Validate the version against the selected mode.
4. Normalize the tag to v{version}.
5. Before presenting the confirmation, inspect all three version views:
   • newest tag by semantic version;
   • newest GitHub Release by publication date;
   • newest stable GitHub Release by semantic version. Report all three when they differ, especially when a pre-release is newer by date but lower by semantic version.

2. Preflight the target commit

Fetch main and tags, then inspect the intended release commit:

git fetch origin main --tags --prune
git rev-parse origin/main
git log --oneline -n 5 origin/main
git tag --list v{version}

Stop if the tag already exists. Confirm that origin/main is the intended release commit; do not tag a feature/worktree branch by accident.

3. Run local validation before tagging

Mirror the release workflow as closely as possible, passing the intended version without editing files:

dotnet restore ReactiveProperty.slnx
dotnet build ReactiveProperty.slnx -c Release --no-restore /p:Version={version} /p:ContinuousIntegrationBuild=True /p:EmbedUntrackedSources=True
dotnet test ReactiveProperty.slnx --no-restore --verbosity normal

If validation fails, stop and fix the failure before tagging. Only skip local validation when the maintainer explicitly asks to rely on GitHub Actions.

4. Optional version record PR

Do this only when the maintainer explicitly asks to record the release version in main before release.

1. Update Source/Directory.Build.props <Version> to the target version.
2. Create a PR and wait for CI/review.
3. Merge the PR.
4. Fetch origin/main again and tag the merged commit.

This PR is optional for the current workflow because the package version is produced from the tag during the release run.