Hi Bryan, On 31.10.2025 07:57, Bryan Ellis wrote: > Question: > > If a Dependabot PR appears during the middle of a release vote — and it > updates a sub-dependency to fix a security issue — **does that invalidate > or terminate the vote?**
No, only the release manager has the authority to cancel a vote. > What exactly are we voting on? > > 1. **The "release vote package"** — the tarball uploaded to `dist/dev`, > created using `npm pack`, representing what a consumer would receive when > installing the package. > 2. **The Git release tag** — the tag created in the repository, which a > consumer could also install directly (e.g., `npm install > github:apache/project-repo#1.0.0`). > 3. **The repository clone** — a developer clones the repo, checks out the > release tag, and runs `npm install` within the repository. This is consistent across the ASF: votes are cast on the source release package, which must be sufficient for a user to build and test the release [1]. Only the source package constitutes an official act of the Foundation. Compiled artifacts (such as those published to NPM) are provided as a convenience to users, but they are not considered an official ASF release. These rules exist because, in compiled languages, it’s difficult to verify that a compiled artifact precisely matches the source. However, thanks to reproducible-build efforts, projects like Log4j also verify the reproducibility of JARs whenever possible. This verification is a prerequisite for allowing releases to be built via GitHub Actions (i.e., on infrastructure not owned or directly controlled by the release manager). ## Vulnerabilities in dependencies If a vulnerability is disclosed in any dependency of the project, I generally follow this rule of thumb: - If you ship the dependency, you effectively own it. You should make a reasonable effort to release versions without “known exploitable vulnerabilities”. - If you do not ship the dependency, it’s sufficient to document its presence. You don’t need to block or reissue a release solely because of it. If your packages include an `npm-shrinkwrap.json` file, I would pause the release to assess the potential impact of the vulnerability. Without it, you can assume that users will receive the same Dependabot PR and handle the update independently. Piotr [1] https://www.apache.org/legal/release-policy.html#artifacts --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
