docs: explicit EOL for previous releases #16263
Conversation
|
|
docs/releases.md
Outdated
| - 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. |
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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:
- Have a visualized graph that highlights currently supported versions (like the one at https://nodejs.org/en/about/previous-releases), ideally auto generated during VitePress build based on the latest Vite version.
- Always list the versions that goes "unsupported" in future release posts.
Co-authored-by: Bjorn Lu <[email protected]>
docs/releases.md
Outdated
| - 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. |
There was a problem hiding this comment.
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:
- Have a visualized graph that highlights currently supported versions (like the one at https://nodejs.org/en/about/previous-releases), ideally auto generated during VitePress build based on the latest Vite version.
- Always list the versions that goes "unsupported" in future release posts.
|
Patak would you like to update this PR still? |
|
@bluwy I updated the PR to avoid the use of EOL. Let me know if the new wording makes sense to you. About having a graph like Node has for EOL, I think that is more useful to know future dates as they are fixed in Node. Maybe could keep updating the "As an example" section for now everytime we do a release so we have the current range there. Or we could play with a graph in another PR if someone has a good idea for it. |
Description
We discussed with @sapphi-red and @dominikg about explicitly documenting our EOL policy (that right now isn't clear, not even between us).
This PR is a proposal that we agreed upon with them, and should help us keep the current low overhead maintenance of previous releases. We can do this only if we continue to be able to move the ecosystem quickly with us, so investment in vite-ecosystem-ci will keep being crucial.
If we merge this PR, we will announce in the Vite social accounts that Vite 2 will be in EOL once we release the next Vite minor to put a date from when we enforce the automatic EOL we are now declaring.