Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!bfmny0!tneff From: tneff@bfmny0.UUCP (Tom Neff) Newsgroups: news.software.b Subject: Re: C News production release bugs Message-ID: <14400@bfmny0.UUCP> Date: 14 Jun 89 02:03:12 GMT References: <1989Jun13.034954.144@utstat.uucp> <3309@epimass.EPI.COM> <1989Jun13.211659.11139@utstat.uucp> Reply-To: tneff@bfmny0.UUCP (Tom Neff) Organization: ^ Lines: 35 In article <1989Jun13.211659.11139@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: >Henry and I discussed modifying version numbers and the like yesterday, >but decided that we don't want to *have* multiple versions of C news in >the field, if we can avoid it. Well intentioned but this is a doomed policy. News is too complex to survive out here in reality without patches and versions. > (We don't particularly like version >numbers like C news 3.11vr2 and do not want to buy into the patchlevel >bureaucracy, since it encourages patches by making them easy. The reality is that if C news needs patching and you do not assume control of the process is a responsive way, the process will go forward unofficially and even more chaos will result. Do you really want "samizdat patches" to get Suns or Strides or whatever working right? > We want C >news to rapidly converge on a stable version.) The stability of a version derives from the quality and thoroughness of the software as distributed - not from the unavailability of fixes. I agree it's possible to get carried away with patch fever - there should be firm goals, say one patchlevel every 6 months for a while, then every year or two - but version numbers MUST exist reliably or things will become a hopeless muddle. Grepping for "/relay" on THIS version, something else NEXT version is no answer. Infrequent updates should be a practical goal, not an obsession. -- You may not redistribute this article for profit. -- Tom Neff UUCP: ...!uunet!bfmny0!tneff "Truisms aren't everything." Internet: tneff@bfmny0.UU.NET