Make prepare-release workflow per-package

[YunchuWang]

Why this is not cosmetic — the current workflow is a destructive trap

.github/workflows/prepare-release.yaml on main cannot express a per-package
release, and running it as-is against the new durable-functions compat package
is destructive and irreversible.

Its "Update package versions" step hardcodes exactly two paths and assigns the
single $NEW_VERSION to both. If an operator runs the workflow with, say,
4.0.0-beta.1 intending to release the compat package:

• packages/durabletask-js 0.4.0 → 4.0.0-beta.1 (core catapulted from 0.4.x to 4.x)
• packages/durabletask-js-azuremanaged 0.3.0 → 4.0.0-beta.1
• packages/azure-functions-durable → untouched (the package actually being released)
• tag created as v4.0.0-beta.1 (wrong namespace)

If any of that ever reaches npm it is irreversible — npm never lets a
name+version pair be reused, even after unpublish.

What this PR changes (workflow + changelog script only)

Reworks the workflow to release one selected package at a time:

• New required package choice input (durabletask-js,
  durabletask-js-azuremanaged, azure-functions-durable) plus an early
  "Resolve package metadata" step mapping the selection to
  pkg_dir, npm_name, tag_prefix, changelog_path:

  input	pkg_dir	npm_name	tag_prefix	changelog_path
  durabletask-js	packages/durabletask-js	@microsoft/durabletask-js	v	CHANGELOG.md
  durabletask-js-azuremanaged	packages/durabletask-js-azuremanaged	@microsoft/durabletask-js-azuremanaged	azuremanaged-v	CHANGELOG.md
  azure-functions-durable	packages/azure-functions-durable	durable-functions	functions-v	packages/azure-functions-durable/CHANGELOG.md

• Threads those outputs through every step: reads the selected package's
  current version, scopes the latest-tag glob to the package's tag_prefix
  (excluding the tag being created), bumps only the selected package.json,
  writes the selected changelog, and creates
  release/<tag_prefix><version> + a <tag_prefix><version> tag.

• Deletes the azuremanaged peerDependencies['@microsoft/durabletask-js']
>=$NEW_VERSION rewrite — packages now version independently, so bumping a
  >=0.3.0 floor on every core release no longer makes sense.

• New guard (azure-functions-durable only): before creating the branch,
  verifies the package's pinned @microsoft/durabletask-js dependency is
  actually published on the public npm registry, failing the run otherwise.
  Core is 0.4.0 in-repo but npm's latest is still 0.3.0, so publishing
  durable-functions today would ship a package whose hard dependency cannot be
  installed (a failure mode already predicted on Add durable-functions@4.0.0 — Azure Functions Durable provider on the gRPC core (+ core host helpers, E2E CI, and release pipeline) #282).

• Summary prints the exact publish command, deriving the dist-tag from the
  version: npm publish --tag preview for prereleases (so they do not move
  latest, with a warning), plain npm publish otherwise.

scripts/update-changelog.js gains an optional 4th positional argument for
the target changelog path (default CHANGELOG.md), so
packages/azure-functions-durable/CHANGELOG.md can be updated without changing
existing 3-argument behavior or the ## Upcoming insertion/reset logic.

Out of scope (deliberately)

No package.json version bumps, no CHANGELOG content, and no npm publish
step (publishing needs a separate decision on NPM_TOKEN vs OIDC trusted
publishing). Only the workflow and the changelog script change.

Notes on the tag-glob (backward compatibility)

With tag_prefix=v, git tag -l "v*" still matches the legacy core tags
(v0.1.0-alpha.1 … v0.3.0) — intended and backward compatible — and never
matches the new azuremanaged-v* / functions-v* namespaces (they start with
a/f, not v).

[Copilot]

Pull request overview

This PR reworks the prepare-release GitHub Actions workflow to make release preparation package-scoped (core, azuremanaged, or azure-functions-durable) to prevent accidental cross-package version/tag churn, and updates the changelog update script to support writing to a non-default changelog path.

Changes:

• Adds a required package input and resolves package-specific metadata (directory, npm name, tag prefix, changelog path) to scope every step to the selected package.
• Updates tagging/branching conventions to use per-package tag prefixes and release/<tag_prefix><version> branches, and improves the summary with package-scoped publish guidance.
• Extends scripts/update-changelog.js with an optional target changelog path argument.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
scripts/update-changelog.js	Adds support for updating a specified changelog file instead of always CHANGELOG.md.
.github/workflows/prepare-release.yaml	Implements per-package release preparation flow (version bump, changelog generation, tagging/branching, and publish guidance).

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

.github/workflows/prepare-release.yaml:132

• grep -v "^${TAG_PREFIX}${NEW_VERSION}$" treats . (and other regex chars) in NEW_VERSION as regex metacharacters, so it can exclude the wrong tag(s) (and not just the exact tag being created). Use fixed-string matching instead for reliable re-runs.

          LATEST_TAG=$(git tag -l "${TAG_PREFIX}*" --sort=-v:refname | \
            grep -v "^${TAG_PREFIX}${NEW_VERSION}$" | head -n 1)

scripts/update-changelog.js:20

• This script isn't idempotent: re-running for the same version inserts a second ## v<version> section. Also, if the target changelog begins with a top-level header (e.g. # Changelog in packages/azure-functions-durable/CHANGELOG.md), the current prepend path moves that header below the new sections. Consider preserving a leading H1 and replacing any existing version section before inserting.

const changelogContent = fs.readFileSync(changelogFile, 'utf8').trim();
let content = fs.readFileSync(targetChangelog, 'utf8');

const newSection = `## v${version} (${releaseDate})

packages/durabletask-js/package.json:20

• The PR description says this change is "workflow + changelog script only", but this PR also modifies package manifests (e.g. adds prepublishOnly and publishConfig.registry). Either update the PR description/scope to explicitly include these package.json changes, or revert them if they’re unintended.

    "test:unit": "jest test --runInBand --detectOpenHandles",
    "prepublishOnly": "npm run build && npm run test"
  },

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (5)

scripts/update-changelog.js:18

• prepare-release now points azure-functions-durable at packages/azure-functions-durable/CHANGELOG.md, which currently starts with a top-level “# Changelog” header and a “## TBD” placeholder (no “## Upcoming”). With the current logic, the script will prepend its own “## Upcoming/## v…” sections above that header and leave the placeholder content behind, producing a malformed/duplicated changelog.

const changelogContent = fs.readFileSync(changelogFile, 'utf8').trim();
let content = fs.readFileSync(targetChangelog, 'utf8');

scripts/update-changelog.js:56

• The script now supports promoting “### Breaking changes” from Upcoming, and the repo’s root CHANGELOG.md has added that scaffold. However, the Upcoming reset template drops the Breaking changes heading, so after the next release it will disappear from the file format.

// Reset the Upcoming section to empty
content = content.replace(/## Upcoming[\s\S]*?(?=\n## v)/, '## Upcoming\n\n### New\n\n### Fixes\n\n');

CHANGELOG.md:7

• The PR description says “No CHANGELOG content” is in scope, but this change adds substantive release notes under Upcoming (e.g., the new “### Breaking changes” entries). Either update the PR description/scope to include these changelog edits, or revert these content changes to keep the PR limited to workflow + script updates.

### Breaking changes

- **`whenAll` no longer fails fast.** A `whenAll` task — and therefore the Durable Functions compat
  `context.df.Task.all()`, which forwards straight to it — now completes only after **every** child
  is terminal, instead of the moment the first child fails. Two user-visible effects: (1) **timing** —

packages/durabletask-js/package.json:20

• The PR description frames the change as “workflow + changelog script only / no package.json changes”, but this diff adds a prepublishOnly hook (build+test) and publishConfig. If intentional, the PR description should be updated to reflect that package publish behavior is also being changed; otherwise these edits should be moved to a separate PR.

    "test:unit": "jest test --runInBand --detectOpenHandles",
    "prepublishOnly": "npm run build && npm run test"
  },

.github/workflows/prepare-release.yaml:132

• The tag-exclusion filter uses regex grep with an unescaped version string. Versions contain '.' and '-' which are regex metacharacters, so this can exclude unintended tags and select the wrong baseline. Use fixed-string whole-line matching instead.

          LATEST_TAG=$(git tag -l "${TAG_PREFIX}*" --sort=-v:refname | \
            grep -v "^${TAG_PREFIX}${NEW_VERSION}$" | head -n 1)

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

packages/azure-functions-durable/README.md:46

• This README says there is “no tracking issue” for the removed v3 entity-lock API, but issue #317 exists (closed as not planned). The statement is factually incorrect and should either link to #317 (not planned) or remove the claim about tracking.

  `context.entities.isInCriticalSection()`. The v3 `df.lock` / `isLocked` surface is **not supported
  and not planned** — there is no tracking issue.

.github/workflows/prepare-release.yaml:132

• The tag-exclusion filter uses a regex pattern with unescaped version text (e.g., dots are wildcards). This can accidentally exclude unrelated tags and pick the wrong baseline for changelog generation. Use fixed-string matching instead.

          LATEST_TAG=$(git tag -l "${TAG_PREFIX}*" --sort=-v:refname | \
            grep -v "^${TAG_PREFIX}${NEW_VERSION}$" | head -n 1)

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (5)

scripts/update-changelog.js:62

• The Upcoming-section reset scaffold drops the new "### Breaking changes" heading that now exists in CHANGELOG.md. After the next release cut, the script will overwrite Upcoming with only New/Fixes, forcing maintainers to re-add Breaking changes manually each time.

// Reset the Upcoming section to empty
content = content.replace(/## Upcoming[\s\S]*?(?=\n## v)/, '## Upcoming\n\n### New\n\n### Fixes\n\n');

.github/workflows/prepare-release.yaml:8

• The workflow header comment lists the tag prefix for durable-functions as "durable-functions-v", but the PR description specifies "functions-v". This inconsistency makes it easy for operators to create tags in an unexpected namespace.

# 3. Updates the package's changelog file and creates a release branch + package-scoped tag
# Packages are versioned and tagged independently (tag prefixes: v, azuremanaged-v, durable-functions-v).
# After the workflow completes, manually open a PR from the release branch to main, then publish

.github/workflows/prepare-release.yaml:67

• For the azure-functions-durable package, TAG_PREFIX is set to "durable-functions-v", but the PR description (and its tag-glob backward-compat notes) describe the namespace as "functions-v". If the intended prefix is "functions-v", this needs to be corrected here or the PR description updated to match.

            azure-functions-durable)
              PKG_DIR="packages/azure-functions-durable"
              NPM_NAME="durable-functions"
              TAG_PREFIX="durable-functions-v"
              CHANGELOG_PATH="packages/azure-functions-durable/CHANGELOG.md"

CHANGELOG.md:15

• The PR description says CHANGELOG content is out of scope ("No CHANGELOG content"), but this change adds new breaking-change entries under the Upcoming section. Either the PR description should be updated to reflect this expanded scope, or the CHANGELOG edits should be moved to a separate PR.

### Breaking changes

- **`whenAll` no longer fails fast.** A `whenAll` task — and therefore the Durable Functions compat
  `context.df.Task.all()`, which forwards straight to it — now completes only after **every** child
  is terminal, instead of the moment the first child fails. Two user-visible effects: (1) **timing** —
  the orchestrator resumes past the `whenAll` only once all siblings finish, not at the first failure;
  (2) **error type** — on failure it throws a JS-native `AggregateError` (`.errors` populated, message
  of the form `"<N> of <M> tasks in the whenAll failed: <child messages joined by '; '>"`) instead of
  re-throwing the first child's own exception. This fixes a lost-failure bug where a later failing
  sibling was dropped against an already-terminal `whenAll`
  ([#301](https://github.com/microsoft/durabletask-js/issues/301)). Fan-out/fan-in is the canonical
  Durable Functions pattern, so review any `Task.all()` error handling that relied on early completion
  or on catching a single child error.

.github/workflows/prepare-release.yaml:136

• The tag-exclusion filter uses grep with a regex pattern built from ${TAG_PREFIX}${NEW_VERSION}. Since grep treats '.' and other characters as regex metacharacters, versions like 0.2.0-beta.1 can match unintended tag names. Use fixed-string matching instead.

          LATEST_TAG=$(git -c versionsort.suffix=- tag -l "${TAG_PREFIX}*" --sort=-v:refname | \
            grep -v "^${TAG_PREFIX}${NEW_VERSION}$" | head -n 1)

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

packages/azure-functions-durable/README.md:46

• The README says there is no tracking issue for restoring the v3 df.lock / isLocked surface, but issue #317 exists (it’s closed as not_planned). This should either reference #317 or remove the “no tracking issue” claim to avoid misleading readers.

  `context.entities.isInCriticalSection()`. The v3 `df.lock` / `isLocked` surface is **not supported
  and not planned** — there is no tracking issue.

.github/workflows/prepare-release.yaml:67

• PR description specifies the compat package tag prefix as functions-v, but this workflow sets it to durable-functions-v. Please align the tag namespace across the PR description, workflow, and release documentation (and the explanatory comments about prefixes).

            azure-functions-durable)
              PKG_DIR="packages/azure-functions-durable"
              NPM_NAME="durable-functions"
              TAG_PREFIX="durable-functions-v"
              CHANGELOG_PATH="packages/azure-functions-durable/CHANGELOG.md"

.github/workflows/prepare-release.yaml:249

• git tag -f + git push -f origin <tag> will move an existing release tag if it already exists, which can rewrite release history. Safer behavior is to only create the tag if it doesn’t exist, or allow it only when it already points to the same commit; otherwise fail with a clear error.

          git tag -f "$TAG_NAME"
          
          # Push branch and tag (force to handle re-runs)
          git push -f origin "$BRANCH_NAME"
          git push -f origin "$TAG_NAME"

[YunchuWang]

This PR is being split into four smaller, independently reviewable PRs, each branched off current main (3ebaf33, after #336 merged). Every file this PR changes is carried by exactly one of them — verified as a set operation: no file lost, none duplicated. Nothing is dropped.

File → carrier PR

File	Now in
.github/workflows/prepare-release.yaml	#337
scripts/update-changelog.js	#337
packages/durabletask-js/package.json	#338
packages/durabletask-js-azuremanaged/package.json	#338
packages/azure-functions-durable/package.json	#338
.github/copilot-instructions.md	#339
CHANGELOG.md	#339
packages/azure-functions-durable/CHANGELOG.md	#339
packages/azure-functions-durable/README.md	#339
doc/release_process.md	#340

• ci(release): per-package prepare-release workflow + changelog script #337 — per-package prepare-release workflow + changelog script (these two files must ship together; the workflow calls the script with a 4th argument that only exists in the updated script)
• build(release): npm publishConfig for all three packages #338 — npm publishConfig for all three packages (smallest; most urgent for publishing)
• docs(release): changelog, README, and copilot-instructions updates #339 — changelog / README / copilot-instructions docs (zero runtime risk)
• docs(release): rewrite release_process.md for the per-package model #340 — release_process.md runbook rewrite

Provenance: for #337 / #338 / #339 the content is byte-identical to this branch at 8501bc0 (already CI-green as a unit); #340's doc/release_process.md is byte-identical to this branch's runbook commit c602302. The four are mutually independent and can merge in any order.

Leaving this PR open so you can confirm nothing was dropped, then close it at your discretion.