should release candidates (rc) be immutable and publicly available?

Sonar Pro

Vote: immutable

Release candidates (RCs) should be **immutable** to ensure security, reproducibility, and trust in the software supply chain. Once published, RCs represent a fixed point for testing and validation; mutability risks supply chain attacks, such as injecting malware or altering assets, which immutable releases explicitly block by locking Git tags and assets.[5] Immutability supports best practices like reproducible builds, deterministic deployments, and reliable rollbacks via new artifact deployments rather than in-place changes, reducing incidents and debugging toil.[6] This is essential for high-availability systems, regulated environments, or frequent deployments where auditability is critical.[6] While mutable RCs might suit low-risk, experimental scenarios, RCs are pre-release testing artifacts meant to be publicly available for broad validation—making immutability non-negotiable to prevent breaking developer workflows or eroding user trust.[5][6] Consistency and predictability in releases further reinforce this.[4]

Grok 4.1 Fast

Vote: immutable

Release candidates (RCs) are pre-final versions intended for broad testing and validation. Immutability ensures that all testers evaluate the exact same artifact, enabling reproducible results and reliable feedback. Mutability risks confusion: changes mid-RC could invalidate prior tests, erode trust, and complicate debugging. Standard practices in git/tags and package managers treat RCs as fixed snapshots. Public availability amplifies this need—immutable RCs allow community scrutiny without version drift. If fixes are needed, create a new RC (e.g., RC2), preserving history and integrity.

GPT-5.4

Vote: immutable

Release candidates should be immutable once published. An RC is meant to be a specific build that can be tested, discussed, and approved with confidence; if it can change underneath the same version tag, test results and bug reports become ambiguous and harder to trust. Immutability also improves reproducibility and supply-chain integrity. Teams need to know that the artifact they validated in CI, staging, or external review is exactly the artifact that others can fetch later. Mutable RCs weaken auditability and make rollback and comparison more difficult. They should also be publicly available in most cases, because wider access improves transparency, enables downstream compatibility testing, and lets users or partners validate before final release. If fixes are needed, publish a new RC identifier (for example, rc2, rc3) rather than replacing the old one.

Kimi K2.5

Vote: immutable

Release candidates must be immutable to ensure testing integrity and reproducibility. Once an RC is tagged and distributed, any modification would invalidate the test results from QA, CI systems, and community validators who tested that specific build. Immutability prevents 'drift' between what was tested and what gets deployed. If a critical bug is found, the proper workflow is to create a new RC (e.g., RC2) rather than mutating the existing artifact. This creates a clear audit trail and ensures that checksums and signatures remain valid. Making RCs immutable also supports supply chain security. Immutable artifacts can be cryptographically verified, cached safely in mirrors, and referenced unambiguously in deployment manifests. Mutable RCs would break dependency resolution and create confusion about which version users are actually running.

Gemini 3.1 Pro

Vote: immutable

Release candidates (RCs) should absolutely be immutable. A core principle of reliable software engineering is that the exact artifact tested and validated in QA must be the exact same artifact deployed to production. If an RC is mutable, it introduces the risk of code, configurations, or dependencies changing after the testing phase. This invalidates the entire quality assurance process and can lead to unexpected bugs in production. Furthermore, immutability ensures strict traceability. When a bug is discovered in an RC, the standard best practice is not to alter the existing build, but rather to fix the issue in the codebase and cut a new, distinct, and immutable release candidate (e.g., moving from RC1 to RC2). This guarantees a reliable and reproducible release pipeline.

Claude Opus 4.6

Vote: immutable

Release candidates should be immutable. The entire purpose of an RC is to be a candidate for the final release — it represents a specific, testable snapshot of the software. If an RC is mutable, then any testing, validation, or sign-off performed against it becomes meaningless, because the artifact could change after the fact. Immutability ensures reproducibility and traceability. When stakeholders, QA teams, or the community test RC1, everyone must be testing the exact same artifact. If a bug is found, you produce RC2 — a new, distinct, and also immutable artifact. This creates a clear audit trail of what was tested and what decisions were made. Making RCs publicly available is also important because it enables broader community testing, which catches issues that internal testing might miss. Public availability combined with immutability builds trust in the release process. Mutable release candidates would undermine the integrity of the release pipeline. They would make it impossible to confidently say 'this exact artifact was tested and approved.' Every serious software project — from Linux distributions to Apache projects to language runtimes — treats RCs as immutable versioned artifacts for exactly these reasons.

Final Summary

The AI Roundtable achieved a rare moment of total alignment, delivering a unanimous verdict in favor of immutable release candidates. Led by Claude Opus 4.6 and Gemini 3.1 Pro, the group argued that allowing an RC to change after publication renders the entire QA process meaningless, while Sonar Pro highlighted the critical security risks of supply chain attacks inherent in mutable artifacts.

No agreement after 1 rounds of discussion. Final vote: immutable: 6

Strongest Arguments

• immutable: If a release candidate is mutable, any testing, validation, or sign-off performed against it becomes meaningless because the artifact could change after the fact; the only way to maintain a reliable audit trail is to issue a new, distinct version (e.g., RC2) for every fix.