# Jenkins Release Process: A Developer's Guide to Weekly Deployments > Understand the Jenkins release process for weekly deployments. Learn how developers submit PRs, add release notes, and how Jenkins automates building and publishing artifacts. - Repository: [Jenkins/jenkins](https://github.com/jenkinsci/jenkins) - Tags: how-to-guide - Published: 2026-08-01 --- **Jenkins follows an automated weekly release cadence every Thursday, where developers submit PRs to the master branch, add release notes to descriptions, and the Jenkins Release Infrastructure handles tagging, building, and publishing artifacts to Maven Central.** The Jenkins release process is a streamlined, developer-centric pipeline designed to deliver reliable weekly stable builds to the community. According to the jenkinsci/jenkins repository, this process combines automated infrastructure with specific developer responsibilities to ensure consistent delivery. Understanding how code moves from commit to published artifact helps contributors align their workflows with the project's regular Thursday release schedule. ## Weekly Release Cycle Jenkins maintains a **regular weekly release cadence** that produces a new stable build every Thursday. This predictable schedule allows developers to plan contributions and ensures users receive frequent updates. The cycle consists of four distinct phases: 1. **Freeze & Tag** – The source tree is frozen at a defined revision and a Git tag (`weekly-`) is created in the repository. 2. **Build & Test** – All modules are built on the dedicated Jenkins Release Environment, executing the full test suite to validate the build integrity. 3. **Artifact Publication** – Successful builds upload artifacts to the Maven repository and refresh the update-center metadata. 4. **Announcement** – Release notes are auto-generated from merged pull request descriptions and published on the Jenkins blog and mailing lists. The complete weekly process is documented in the "Weekly release process" section of `docs/MAINTAINERS.adoc` within the core repository. ## Developer Responsibilities in the Jenkins Release Process Contributors play an active role in the Jenkins release process through specific actions that ensure code quality and documentation accuracy. These responsibilities bridge the gap between feature development and production deployment. ### Writing and Reviewing Code Developers submit Pull Requests targeting the `master` branch. Each PR must use the Jenkins test harness to verify that changes build correctly and pass unit and integration tests. This test-driven approach prevents regressions from entering the release stream. ### Documenting Changes with Release Notes In the PR description, developers must add a concise change entry under the `## Release notes` heading. The release job harvests this text to compile the weekly changelog. For example: ```yaml ## Release notes - Fixed a race condition in the QueueItem handling (JENKINS-12345) ``` This practice guarantees end-users receive clear descriptions of improvements and fixes. ### Passing CI Validation The Jenkins CI runs `mvn clean install -DskipTests=false` via the *jenkinsci/jenkins* job. PRs must achieve a green status before merging, ensuring reproducible builds and preventing integration failures. ### Timing Merges with the Release Window Ideally, developers merge PRs before the **freeze point**, usually occurring on Monday of the release week. Merges after the freeze defer to the next weekly cycle, aligning code changes with the upcoming tag and reducing last-minute integration risks. ### Manual Release Approval Occasionally, developers participate in manual approval steps for release jobs, such as confirming artifact signatures. This provides an additional verification layer for critical releases. ## Release Job Architecture The actual release execution is performed by a set of Jenkins jobs defined in the **jenkins-infra/release** repository. These jobs run on a dedicated Release Environment that mirrors production, guaranteeing reproducibility. Key jobs include: - **`jenkins-release`** – Orchestrates the overall workflow, managing freeze, build, and publish phases. - **`jenkins-release-test`** – Executes the full test matrix on a clean workspace to catch environment-specific issues. - **`jenkins-publish-update-center`** – Generates the [`update-center.json`](https://github.com/jenkinsci/jenkins/blob/main/update-center.json) file that Jenkins instances consume to discover updates. The environment configurations and detailed Job DSL scripts are maintained in the external infrastructure repository. ## Post-Release Verification After a weekly tag is created and published, several automated actions complete the distribution: 1. **Maven Availability** – Artifacts publish to Maven Central under `org.jenkins-ci.main:jenkins-war`. 2. **Update Center Refresh** – The [`update-center.json`](https://github.com/jenkinsci/jenkins/blob/main/update-center.json) metadata updates, making the new version immediately available in the Jenkins UI. 3. **Documentation Publication** – Auto-generated release notes appear on the Jenkins website. Developers can verify releases by pulling the latest weekly Docker image or downloading the WAR file directly: ```bash # Retrieve the most recent weekly WAR from Maven Central curl -O https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-war/weekly/jenkins-war-2.452.1.war ``` Replace the version number with the latest tag shown on the release page. ## Key Source Files Several files within the repository define the technical backbone of the release pipeline: - **`docs/MAINTAINERS.adoc`** – Contains the canonical weekly release process documentation and maintainer guidelines. - **[`pom.xml`](https://github.com/jenkinsci/jenkins/blob/main/pom.xml)** (root) – Defines Maven build configuration, dependency management, and release packaging settings. - **[`src/main/java/hudson/model/UpdateCenter.java`](https://github.com/jenkinsci/jenkins/blob/main/src/main/java/hudson/model/UpdateCenter.java)** – Implements the logic for generating [`update-center.json`](https://github.com/jenkinsci/jenkins/blob/main/update-center.json) metadata consumed by Jenkins instances after each release. ## Summary - Jenkins releases follow a **fixed weekly schedule every Thursday**, creating predictable delivery cycles for developers and users. - Developers must add **release notes to PR descriptions** under the `## Release notes` heading for automatic changelog generation. - The **freeze point** typically occurs on Monday; merge PRs before this deadline to include them in the upcoming weekly build. - Release jobs in the **jenkins-infra/release** repository orchestrate tagging, building, and publishing to Maven Central. - The **[`UpdateCenter.java`](https://github.com/jenkinsci/jenkins/blob/main/UpdateCenter.java)** class manages update-center metadata that distributes releases to Jenkins installations worldwide. ## Frequently Asked Questions ### When is the weekly Jenkins release published? Jenkins publishes a new **weekly-stable release every Thursday**. The process begins with a code freeze early in the week, followed by automated building, testing, and publication to Maven repositories and the update center. ### How do I ensure my changes appear in the next Jenkins release? Merge your Pull Request before the **freeze point**, typically occurring on Monday of the release week. Include a release note entry in your PR description under the `## Release notes` heading, and ensure the CI build passes with `mvn clean install -DskipTests=false`. ### Where are Jenkins release artifacts published? Weekly release artifacts are published to **Maven Central** under the coordinates `org.jenkins-ci.main:jenkins-war`. The `jenkins-publish-update-center` job also updates the [`update-center.json`](https://github.com/jenkinsci/jenkins/blob/main/update-center.json) file, making new versions immediately available through the Jenkins UI. ### What is the role of the jenkins-infra/release repository? The **jenkins-infra/release** repository contains the Jenkins Release Environment configuration and Job DSL scripts that drive the weekly release pipeline. It defines the `jenkins-release`, `jenkins-release-test`, and `jenkins-publish-update-center` jobs that execute the freeze, build, test, and publish phases.