[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] RFC: Version support policy



Jan Beulich writes ("Re: [PATCH] RFC: Version support policy"):
> 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.

Yes.  This is intending to cover all dependencies of whatever nature.

> 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.

This is a valid concern.  I was thinking about this and I think
something needs to be written about this somewhere but the REAME isn't
the right place.  CODING_STYLE maybe.

> > 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).

I don't think that is workable.  Effectively, it means we are
targeting a constantly-obsolescing dependency environment.  It
would prevent us from adopting even very-well-established facilities
and improvements in our dependencies.

Effectively, it would force us to continue to write using 10- or
20-year-old idioms.  Idioms many of which have been found to be
suboptimal, and which in some cases are becoming unsupported.

Ian.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.