> On Aug 19, 2021, at 10:18 AM, Jan Beulich <jbeul...@suse.com> wrote: > > On 13.08.2021 13:37, Ian Jackson wrote: >> The current policy for minimum supported versions of tools, compilers, >> etc. is unsatisfactory: For many dependencies no minimum version is >> specified. For those where a version is stated, updating it is a >> decision that has to be explicitly taken for that tool. > > Considering your submission of this having been close to a glibc > version issue you and I have been discussing, I wonder whether > "etc" above includes library dependencies as well. > > In any event the precise scope of what is meant to be covered is > quite important to me: There are affected entities that I'm happy > to replace on older distros (binutils, gcc). There are potentially > affected entities that I'm less happy to replace, but at the time > I did work my way through it for example for Python (to still be > able to build qemu, the community of which doesn't appear to care > at all to have their stuff buildable in older environments). The > point where I'd be really in trouble would be when base platform > libraries like glibc are required to be a certain minimum version: > I'd then be (potentially severely) restricted in what systems I > can actually test stuff on.
The question here is, why would someone running a 10-year-old distro that’s been out of support for 6 years want to run a bleeding edge version of Xen? I understand wanting to run Xen 4.16 on (say) Ubuntu 18.04, but who on earth would want to run Xen 4.16 on Ubuntu 14.04, and why? If such people exist, is it really worth the effort to try to support them? > In addition I see a difference between actively breaking e.g. > building with older tool chains vs (like you have it in your > README adjustment) merely a statement about what we believe > things may work with, leaving room for people to fix issues with > their (older) environments, and such changes then not getting > rejected simply because of policy. Yes; I think the principle should be that we *promise* to keep it working on the currently-supported releases of a specific set of distros (e.g., Debian, Ubuntu, Fedora, SUSE, RHEL). Working on older versions can be best-effort; if simple changes make it compatible with older versions, and aren’t too burdensome from a code complexity point of view, they can be accepted. One of the issues however is build-time checks. If we have a build-time check for version X, but only test it on X+10 or later, then the build may break in strange ways when someone tries it on something in between. I think it’s too much effort to ask developers to try to find the actual minimum version of each individual dependency as things evolve. > While generally I find Marek's proposal better to tie the baseline > to distros of interest, in a way it only shifts the issue, I'm > afraid. What do you mean “shifts the issue”? You mean shifts it from versions of individual components to versions of distros? That’s why I think we should support only currently-supported distros. If the distro’s maintainers don’t consider the distro worth supporting any more, I don’t see why we should make the effort to do so. -George
signature.asc
Description: Message signed with OpenPGP
