|
| 1 | +# Deprecation Policy for vLLM |
| 2 | + |
| 3 | +This document outlines the official policy and process for deprecating features in the vLLM project. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +vLLM uses a structured "deprecation pipeline" to guide the lifecycle of deprecated features. This policy ensures that users are given clear and sufficient notice when a feature is deprecated and that deprecations proceed in a consistent and predictable manner. |
| 8 | + |
| 9 | +We aim to strike a balance between continued innovation and respecting users’ reliance on existing functionality. Deprecations are tied to our **minor (Y) releases** following semantic versioning (X.Y.Z), where: |
| 10 | +- **X** is a major version (rare) |
| 11 | +- **Y** is a minor version (used for significant changes, including deprecations/removals) |
| 12 | +- **Z** is a patch version (used for fixes and safer enhancements) |
| 13 | + |
| 14 | +## Deprecation Pipeline |
| 15 | + |
| 16 | +The deprecation process consists of several clearly defined stages that span multiple Y releases: |
| 17 | + |
| 18 | +### 1. **Deprecated (Still On By Default)** |
| 19 | +- **Action**: Feature is marked as deprecated. |
| 20 | +- **Timeline**: A removal version is explicitly stated in the deprecation warning (e.g., "This will be removed in v0.10.0"). |
| 21 | +- **Communication**: Deprecation is noted in the following, as applicable: |
| 22 | + - Help strings |
| 23 | + - Log output |
| 24 | + - API responses |
| 25 | + - `/metrics` output (for metrics features) |
| 26 | + - User-facing documentation |
| 27 | + - Release notes |
| 28 | + - GitHub Issue (RFC) for feedback |
| 29 | + |
| 30 | +### 2. **Deprecated (Off By Default)** |
| 31 | +- **Action**: Feature is disabled by default, but can still be re-enabled via a CLI flag or environment variable. Feature throws an error when used without re-enabling. |
| 32 | +- **Purpose**: Allows users who missed earlier warnings a temporary escape hatch while signaling imminent removal. Ensures any remaining usage is clearly surfaced and blocks silent breakage before full removal. |
| 33 | + |
| 34 | +### 3. **Removed** |
| 35 | +- **Action**: Feature is completely removed from the codebase. |
| 36 | +- **Note**: Only features that have passed through the previous deprecation stages will be removed. |
| 37 | + |
| 38 | +## Example Timeline |
| 39 | + |
| 40 | +Assume a feature is deprecated in `v0.9.0`. |
| 41 | + |
| 42 | +| Release | Status | |
| 43 | +|---------------|-------------------------------------------------------------------------------------------------| |
| 44 | +| `v0.9.0` | Feature is deprecated with clear removal version listed. | |
| 45 | +| `v0.10.0` | Feature is now off by default, throws an error when used, and can be re-enabled for legacy use. | |
| 46 | +| `v0.11.0` | Feature is removed. | |
| 47 | + |
| 48 | +## Important Guidelines |
| 49 | + |
| 50 | +- **No Removals in Patch Releases**: Removing deprecated features in patch (`.Z`) releases is disallowed to avoid surprising users. |
| 51 | +- **Grace Period for Existing Deprecations**: Any feature deprecated **before this policy** will have its grace period start **now**, not retroactively. |
| 52 | +- **Documentation is Critical**: Ensure every stage of the pipeline is documented clearly for users. |
| 53 | + |
| 54 | +## Final Notes |
| 55 | + |
| 56 | +This policy is a living document and may evolve as the needs of the project and its users change. Community feedback is welcome and encouraged as we refine the process. |
0 commit comments