Llm-d-inference-scheduler V0.4.0 Release Guide

Nov 24, 2025 by Alex Johnson 47 views

Releasing new versions of software requires a well-defined process to ensure consistency, quality, and transparency. This article outlines the step-by-step procedure for releasing version 0.4.0 of the llm-d-inference-scheduler, a crucial component in the llm-d ecosystem. Following this guide meticulously will help maintain a smooth release cycle and keep the community informed.

Introduction
Prerequisites
Release Process
Announce the Release
Final Steps

Introduction

The primary purpose of this document is to detail the release process for llm-d-inference-scheduler. This includes everything from setting up the environment to announcing the release to the community. The llm-d-inference-scheduler plays a pivotal role in managing inference tasks within the broader llm-d framework. A structured release process ensures that each new version is stable, reliable, and easily integrated by users. This guide is designed to be comprehensive, providing clear instructions for each step, thereby minimizing the risk of errors and ensuring a consistent output for every release. It serves as a single source of truth for anyone involved in the release management of this critical component. Regular adherence to this process not only guarantees a high standard of quality but also facilitates easier collaboration and knowledge sharing among the development team.

Prerequisites

Before initiating the release process, several prerequisites must be met to ensure a smooth and successful operation. These prerequisites include necessary permissions, environment variable configurations, and repository setup. Verifying these elements beforehand prevents potential roadblocks and ensures that the release process can proceed without interruptions. Properly configuring the environment and having the right permissions are foundational steps. Failing to meet these prerequisites can lead to failed builds, inability to push changes, and ultimately, a delayed or unsuccessful release. Each step here is crucial for maintaining the integrity of the llm-d-inference-scheduler and its release cycle. By taking the time to confirm these prerequisites, the release manager sets the stage for a well-executed release.

Permissions to push to the llm-d-inference-scheduler repository are essential. This ensures you have the authority to make necessary changes and tag commits.
Set the required environment variables based on the expected release number. This includes setting the MAJOR, MINOR, and PATCH version numbers, as well as the remote repository:
```
export MAJOR=0
export MINOR=4
export PATCH=0
export REMOTE=origin
```
If creating a release candidate, set the release candidate number:
```
export RC=1
```

If needed, clone the llm-d-inference-scheduler repo:

git clone -o ${REMOTE} git@github.com:llm-d/llm-d-inference-scheduler.git

Release Process

The release process is a multi-stage operation that includes branching, tagging, and building. Each stage is designed to ensure the integrity and stability of the released version. This systematic approach helps to maintain a clear and traceable history of changes, making it easier to identify and address any issues that may arise. By following a structured release process, the team can minimize the risk of introducing errors and ensure that each release meets the required standards. The process is divided into distinct steps to allow for better management and oversight, ensuring that each aspect of the release is carefully handled. This meticulous approach contributes to the overall reliability of the llm-d-inference-scheduler and the confidence users have in each new version.

Create or Checkout Branch

Managing branches effectively is a crucial part of the release process. This involves either creating a new branch for a release candidate or checking out an existing branch for major, minor, or patch releases. Proper branch management ensures that development efforts are isolated and that changes can be safely integrated into the release. This step is vital for maintaining a clean and organized codebase, which is essential for collaboration and stability. Incorrect branch handling can lead to code conflicts and integration issues, so it’s important to follow these steps carefully. By maintaining well-defined branches, the development team can work more efficiently and reduce the risk of introducing errors into the main codebase. This disciplined approach to branch management is a cornerstone of a successful release process.

If you already have the repo cloned, ensure it’s up-to-date and your local branch is clean.
Release Branch Handling:
- For a Release Candidate:
  - Create a new release branch from the main branch. The branch should be named release-${MAJOR}.${MINOR}, for example, release-0.1:
```
git checkout -b release-${MAJOR}.${MINOR}
```
- For a Major, Minor or Patch Release:
  - A release branch should already exist. In this case, check out the existing branch:
```
git checkout -b release-${MAJOR}.${MINOR} ${REMOTE}/release-${MAJOR}.${MINOR}
```
Push your release branch to the llm-d-inference-scheduler remote.
```
git push ${REMOTE} release-${MAJOR}.${MINOR}
```

Tag Commit and Trigger Image Build

Tagging commits and triggering image builds are essential steps in the release process. Tagging creates a snapshot of the codebase at a specific point in time, allowing for easy reference and retrieval of past releases. Triggering an image build automates the process of creating a container image, ensuring consistency and reliability across different environments. This step is crucial for distributing the llm-d-inference-scheduler as a containerized application. Automated image builds reduce the risk of human error and ensure that the release artifacts are always up-to-date. This process also facilitates testing and deployment, making it easier to integrate the new release into production systems. By tagging commits and automating image builds, the team can streamline the release pipeline and ensure that the software is delivered efficiently and reliably.

Tag the head of your release branch with the sem-ver release version.

For a release candidate:

git tag -s -a v${MAJOR}.${MINOR}.${PATCH}-rc.${RC} -m 'llm-d-inference-scheduler v${MAJOR}.${MINOR}.${PATCH}-rc.${RC} Release Candidate'

For a major, minor or patch release:

git tag -s -a v${MAJOR}.${MINOR}.${PATCH} -m 'llm-d-inference-scheduler v${MAJOR}.${MINOR}.${PATCH} Release'

Push the tag to the llm-d-inference-scheduler repo.
- For a release candidate:
```
git push ${REMOTE} v${MAJOR}.${MINOR}.${PATCH}-rc.${RC}
```
- For a major, minor or patch release:
```
git push ${REMOTE} v${MAJOR}.${MINOR}.${PATCH}
```
Pushing the tag triggers CI action to build and publish the container image to the ghcr registry. This automated process ensures that a container image is built for every tagged release, making it easily accessible for deployment.
Test the steps in the tagged quickstart guide after the PR merges. TODO add e2e tests! Comprehensive testing is crucial to ensure the stability and reliability of the release.

Create the Release!

Creating the release on the platform is a critical step that makes the new version officially available. This involves packaging the software, generating release notes, and making the release accessible to users. A well-executed release creation process ensures that users have a clear understanding of the changes and improvements in the new version. This step also includes generating release notes, which provide a summary of the changes, bug fixes, and new features. Clear and informative release notes are essential for user adoption and satisfaction. By carefully creating the release, the team ensures that the software is delivered in a user-friendly manner, making it easier for users to upgrade and take advantage of the latest features.

Create a new release:
1. Choose the tag that you created for the release. Selecting the correct tag ensures that the release corresponds to the intended version of the code.
2. Use the tag as the release title, i.e. v0.1.0 refer to previous release for the content of the release body. Consistency in naming conventions helps users easily identify the release.
3. Click "Generate release notes" and preview the release body. Automatically generating release notes saves time and ensures that all changes are documented.
4. Go to Gateway Inference Extension latest release and make sure to include the highlights in llm-d-inference-scheduler as well. Including highlights ensures that key changes are prominently featured in the release notes.
5. If this is a release candidate, select the "This is a pre-release" checkbox. Marking a release as a pre-release indicates that it is not yet intended for production use.
If you find any bugs in this process, create an issue. Reporting bugs helps improve the release process for future releases.

Announce the Release

Announcing the release is a crucial step in informing the community and users about the new version of the software. A well-crafted announcement ensures that users are aware of the new features, bug fixes, and improvements. This step is vital for driving adoption and ensuring that users can take advantage of the latest enhancements. The announcement should be clear, concise, and informative, providing users with all the necessary details to upgrade and use the new version effectively. By proactively communicating the release, the team can foster a strong relationship with the user community and ensure that everyone is informed about the latest developments in the llm-d-inference-scheduler.

Use the following steps to announce the release.

Send an announcement email to llm-d-contributors@googlegroups.com with the subject:
```
[ANNOUNCE] llm-d-inference-scheduler v${MAJOR}.${MINOR}.${PATCH} is released
```
Add a link to the final release in this issue. This provides a direct reference to the release information for anyone following the issue.
Close this issue. Closing the issue signifies that the release process is complete.

Final Steps

The final steps in the release process are crucial for ensuring that all aspects of the release have been properly addressed. This includes verifying that all documentation is up-to-date and that any follow-up tasks have been scheduled. By completing these final checks, the team can ensure that the release is well-documented and that any remaining issues are addressed in a timely manner. These steps help to maintain the overall quality and reliability of the llm-d-inference-scheduler. They also facilitate ongoing maintenance and support, making it easier to address user feedback and plan for future releases. Completing these final steps ensures a smooth transition to the new version and sets the stage for continued improvement and development.

For more information on software release management best practices, check out this comprehensive guide from Atlassian.