On Fri, 11 Jan 2019, Paul E. McKenney wrote: > On Fri, Jan 11, 2019 at 12:20:45AM +0100, Andrea Parri wrote: > > > > I'm not all that exited about spreading version requirements in the > > > > source: we report this requirement in our README, and apparently we > > > > already struggle to keep this information up-to-date. So what about > > > > squashing something like the below (assume that 7.52 will be released > > > > by the time this patch hit mainline; if this won't be the case, we > > > > may consider using the development version 7.51+6)? notice that this > > > > also removes an (obsolete, at this point) comment from lock.cat. > > > > > > Sounds like a very good point to me! > > > > > > Should have pointers in the various files to the README file? Or maybe > > > get people used to using scripting that checks versions? Or maybe > > > after answering questions for some time, people will get used to > > > checking versions? > > > > As discussed off-list: I have no strong opinion on this regard, well, > > except that I think we ought to fix the README, somehow (consider my > > diff below as a first proposal). Akira actually preceded me on this > > and suggested another solution [1]. > > > > Andrea > > > > [1] http://lkml.kernel.org/r/04d15c18-d210-e3da-01e2-483eff135cb7@xxxxxxxxx > > My concern with this approach is that it seems to me to implicitly promise > that herd will provide backwards compatibility, which is a real pain to > test, let alone to provide. Yes, the latest version of herd probably > supports latest mainline, but will five-years-from-now herd work correctly > on the .bell, .cat, and .def files from current mainline? The README file can say something along the lines of: Herd version 7.52 (later versions may or may not be compatible). Herd can be downloaded from... Alan
