In the Wasmtime meeting today we discussed #10074 and some related questions about MSRV/security patches. Wasmtime's current release process guarantees security fixes for 2 releases of Wasmtime, the current and previous release. This is not a large window and there will always be users who prefer stability/unchanging foundations rather than bumping the Wasmtime dependency each month.
One of the chief points brought up in the meeting would be to possible have an LTS release for Wasmtime. @fitzgen proposed perhaps every 10th version of Wasmtime as something easy to remember. I believe the roughly-agreed-upon definition of an LTS would look something like:
- The MSRV of the release in question would not change over its lifetime, even for security updates.
- Security fixes are guaranteed to be backported/released to releases in question.
- Bug fixes will be provided if we're explicitly requested to do it.
On the last point I don't think we can reasonably go through all bug fixes and proactively see if they're affecting older releases myself, but others may disagree!
I wanted to open this issue to have discussion of: should we do this? What are the exact/parameters/definition of an LTS we'd want?
Personally my thoughts are that I think something like this could make sense. One requirement I think we would want though is that LTS windows for releases would overlap slightly. For example of 20 is an LTS for only 10 releases then it means that as soon as 30 is released then 20 is no longer supported. That means there's no window for updating older LTS releases to a new LTS release where the old one is still supported. For me I'd probably say that we should overlap LTS windows by 2 release, meaning they're 2 months wide.
If we did that overlap then it would mean that any particular LTS release would be supported for 1 year. The last two months of that year users would be encouraged to update to the next LTS. This wouldn't mean though that we would always produce an LTS release once a year because LTS itself would be produced once every 10 months.
Personally I don't know how much effort it would be to maintain a year-old version of Wasmtime. Naively it doesn't seem like too too much work, but I would acknowledge there's a lot of unknown unknowns here. One of my chief concerns would be about keeping release automation up-to-date. Namely we'd probably want some sort of automated process which forces us to check in on LTS automation once a month or something like that to ensure it still works. Apart from that though 10 doesn't seem like an unreasonable window to support things.
If we do agree on LTS and every-10-versions there's also the nice coincidence that Wasmtime 30 will be branched in a little less than a week...
In the Wasmtime meeting today we discussed #10074 and some related questions about MSRV/security patches. Wasmtime's current release process guarantees security fixes for 2 releases of Wasmtime, the current and previous release. This is not a large window and there will always be users who prefer stability/unchanging foundations rather than bumping the Wasmtime dependency each month.
One of the chief points brought up in the meeting would be to possible have an LTS release for Wasmtime. @fitzgen proposed perhaps every 10th version of Wasmtime as something easy to remember. I believe the roughly-agreed-upon definition of an LTS would look something like:
On the last point I don't think we can reasonably go through all bug fixes and proactively see if they're affecting older releases myself, but others may disagree!
I wanted to open this issue to have discussion of: should we do this? What are the exact/parameters/definition of an LTS we'd want?
Personally my thoughts are that I think something like this could make sense. One requirement I think we would want though is that LTS windows for releases would overlap slightly. For example of 20 is an LTS for only 10 releases then it means that as soon as 30 is released then 20 is no longer supported. That means there's no window for updating older LTS releases to a new LTS release where the old one is still supported. For me I'd probably say that we should overlap LTS windows by 2 release, meaning they're 2 months wide.
If we did that overlap then it would mean that any particular LTS release would be supported for 1 year. The last two months of that year users would be encouraged to update to the next LTS. This wouldn't mean though that we would always produce an LTS release once a year because LTS itself would be produced once every 10 months.
Personally I don't know how much effort it would be to maintain a year-old version of Wasmtime. Naively it doesn't seem like too too much work, but I would acknowledge there's a lot of unknown unknowns here. One of my chief concerns would be about keeping release automation up-to-date. Namely we'd probably want some sort of automated process which forces us to check in on LTS automation once a month or something like that to ensure it still works. Apart from that though 10 doesn't seem like an unreasonable window to support things.
If we do agree on LTS and every-10-versions there's also the nice coincidence that Wasmtime 30 will be branched in a little less than a week...