-
-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: explicit EOL for previous releases #16263
Merged
Merged
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,13 +8,25 @@ A full changelog of past releases is [available on GitHub](https://github.com/vi | |
|
|
||
| Vite does not have a fixed release cycle. | ||
|
|
||
| - **Patch** releases are released as needed. | ||
| - **Minor** releases always contain new features and are also released as needed. Minor releases always go through a beta pre-release phase. | ||
| - **Major** releases generally align with [Node.js EOL schedule](https://endoflife.date/nodejs), and will be announced ahead of time. These releases will go through an early discussion phase, and both alpha and beta pre-release phases. | ||
| - **Patch** releases are released as needed (usually every week). | ||
| - **Minor** releases always contain new features and are released as needed. Minor releases always have a beta pre-release phase (usually every two months). | ||
| - **Major** releases generally align with [Node.js EOL schedule](https://endoflife.date/nodejs), and will be announced ahead of time. These releases will go through long-term discussions with the ecosystem, and have alpha and beta pre-release phases (usually every year). | ||
|
|
||
| The previous Vite Major will keep receiving important fixes and security patches. After that, it would only get updates if there are security concerns. We recommend updating Vite regularly. Check out the [Migration Guides](https://vitejs.dev/guide/migration.html) when you update to each Major. | ||
| The Vite team supports previous Vite versions until their End of Life (EOL). The EOL for each release is automatically determined by: | ||
|
|
||
| The Vite team partners with the main projects in the ecosystem to test new Vite versions before they are released through the [vite-ecosystem-ci project](https://github.com/vitejs/vite-ecosystem-ci). Most projects using Vite should be able to quickly offer support or migrate to new versions as soon as they are released. | ||
| - **Current Minor** gets regular fixes. | ||
| - **Previous Major** (only for its latest minor) and **Previous Minor** receives important fixes and security patches. | ||
| - **Second-to-last Major** (only for its latest minor) and **Second-to-last Minor** receives security patches. | ||
| - All versions before these are considered to have reached their EOL. | ||
|
|
||
| As an example, if the Vite latest is at 5.3.10: | ||
|
|
||
| - Regular patches are released for `[email protected]`. | ||
| - Important fixes and security patches are backported to `vite@4` and `[email protected]`. | ||
| - Security patches are also backported to `vite@3` and `[email protected]`. | ||
| - `vite@2` and `[email protected]` reached their EOL. | ||
|
|
||
| We recommend updating Vite regularly. Check out the [Migration Guides](https://vitejs.dev/guide/migration.html) when you update to each Major. The Vite team works closely with the main projects in the ecosystem to ensure the quality of new versions. We test new Vite versions before releasing them through the [vite-ecosystem-ci project](https://github.com/vitejs/vite-ecosystem-ci). Most projects using Vite should be able to quickly offer support or migrate to new versions as soon as they are released. | ||
|
|
||
| ## Semantic Versioning Edge Cases | ||
|
|
||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A little bit scary to say that Vite 5.0 would already be EOL 😅 I'm not sure how to re-word it, but I suppose it's because we consider EOL on a minor level while other tools consider on the major level only.
Not a blocker though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we need a new name like "minor-EOL". I think it is good to be explicit, if we have 5.10, it doesn't scale to be backporting fixes to 5.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally I don't think we have to backport fixes to different minors on the current major. I notice we do that for security fixes which felt a bit overkill. Minor/patches are non-breaking so there isn't a reason for them not to upgrade all the way to latest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think backporting security fixes at least to the prev 2 minors is a good idea given that some downstream projects may have the minor pinned because they are using experimental features. This has been very common in Nuxt for example. They should move as fast as they can though, so we only need the last one or two minors.
We could remove the explicit minor EOL, but I still prefer to have it so there is a clear contract with downstream projects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they pin the versions then they should also upgrade as soon as possible, otherwise EOL is only going to prolong it 😬 But anyways we can revise this again in the future, I'm ok with merging this for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that EOL has a somewhat different connotation from, and sounds much stronger than "versions that will no longer receive updates". Usually it is only associated with major versions or entire projects.
Maybe this whole section should just be renamed "Supported Version Ranges", and instead of EOL, use "unsupported" or "no longer supported".
Since the range isn't always straightforward, we should probably: