Re: [PATCH] RFC: Version support policy

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

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.

> The result is persistent debates over what is good to support,
> conducted in detail in the context of individual patches.
> 
> Decisions about support involve tradeoffs, often tradeoffs between the
> interests of different people.  Currently we don't have anything
> resembling a guideline.  The result is that the individual debates are
> inconclusive; and also, this framework does not lead to good feelings
> amongst participants.
> 
> I suggest instead that we adopt a date-based policy: we define a
> maximum *age* of dependencies that we will support.
> 
> The existing documentation about actually known working versions
> then becomes a practical consequence of that policy.
> 
> In this patch I propose a cutoff of 6 years.
> Obviously there will be debate about the precise value.

Indeed I consider this way too short. Purely as a personal (and
abstract) view (realizing this isn't really practical, and knowing
there are reasons why I'd actually like to see a bump of the
baseline) I'd prefer if there weren't minimum version requirements
at all (apart from maybe - along the lines of ...

> It will also be necessary to make exceptions, and/or to make different
> rules for different architectures.  In particular, new architectures,
> new configurations, or new features, may need an absolute earliest
> tooling date which is considerably less than the usual limit.

... this - a baseline determined when Xen became an open source
project). Advanced features may of course be dependent on better
capabilities, as long as there's a way to disable building or
use of these features.

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.

Jan