On 2023/10/16 14:54, Jeremy Guthrie wrote: > > On Oct 13, 2023, at 2:55 PM, hvjunk <hvjunk@xxxxxxxxx> wrote: > > > > What I guess the OP "wants" is to say that version 9.5 will be supported for the next 3-5 years, and all the security patches be backported from versions 11,12,13,14,15 to 9.5.3-patch1234 etc. Since OpenSSH/etc. haven't changed the wire protocol in like 20odd years, I don't personally see a reason to require such, given the RFC standards for the protocol, given the number of competitors out there. > > > > That said,perhaps the OpenSSH devs could state something like this to clear the "EOL" problem easily: the latest version will be the version we'll patch for security, any version before that we deemed EOL and won't support and ask you to first upgrade and test before making the bug submission. > > > > Yes, I would say above is the ballpark I was hoping to get clarification on. In the end if a security bug came out, having a clear EOL policy lets you clearly tell your user-base when to expect versions will be retired and no longer taken care of. The longer the tail on software fixes the more effort it will take and technical debt you’re maintaining. > > Swag Example: We provide fixes only for the latest releases of the last two major versions. e.g. 8.X, and 9.X. Once 10.X, comes out, we stop supporting 8.X, etc… I am not asking for a year commit, just trying to understand what the community feels like would be a good level of backward porting of fixes until some EOL date. It is okay if people do not have an answer, just wanted to see if this had been discussed before. That sort of policy is useful for software which updates multiple branches in parallel, so you know when to switch to a newer "major version", but not really where there's one main branch from which releases are made and fixes are generally distributed by releasing a new version (as is the case with OpenSSH). Downstream distributors of OpenSSH are free to (and often do) make their own backported patches for old versions, but that's something which they're responsible for themselves. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
