[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.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |