Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ukma!rutgers!dayton!jad From: jad@dayton.UUCP (J. Deters) Newsgroups: news.software.b Subject: Re: Patch dates or Patch Numbers Summary: Patch Numbers. Definitely. Message-ID: <6717@dayton.UUCP> Date: 16 Aug 89 22:42:47 GMT References: <1989Aug9.164003.20669@utzoo.uucp> Reply-To: jad@dayton.UUCP (J. Deters) Organization: Terrapin Transit Authority Lines: 57 In article <1989Aug9.164003.20669@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >more problems than it solves. So far I see little evidence for this. >Convincing us is going to require good arguments, not endless repetition >of poor ones. A correctly used patch system will need numbers. Not want. Need. If you want to know where your program is in relation to the patch you have, a system of Release.Revision.PatchLevel is almost mandatory. Dates hide the history of the code without substantial digging into documentation. I'd hate to have to go through the posting to find the README file that has a list of release dates and changes to find that I missed a release somewhere, when it is intuitively obvious that 5.4.1 is 4 releases higher than my current 1.3.6. :-) This also tells me that many things such as file layouts, etc. have probably changed since I put my code in, while 5.5 probably will drop right on top of 5.4.6 without my worrying about it. You may think that the general public knows enough about your code to know that you put in a widget-seeking algorithm that restructures your save file when you went from 5/21/86-3 to 7/01/86, but it's not obvious by looking at those dates. 3.7.6 to 4.0 kind of stands out as a warning. Set it up so that if a Release comes out, you know to dump any source code you have and re-install the new source. If a Revision comes out, you know that you can apply it to ANY previously applied Revisions to this release. Cumulative patches in the Revisions make life easier for the installers. You don't have to waste hundreds, if not thousands of net.dollars posting messages like "Can somebody send me foobar 12/15/88? I have foobar 12/01/88 but I just received foobar patch 12/15/88 patch 1" Instead, you *know* that foobar 3.2 can be applied to foobar 3.0. If a PatchLevel comes out, you must apply it to the appropriate Release and Revision, but you may or may not need previous PatchLevels depending on your philosophy of distribution. I personally prefer cumulative patches, such that 3.2.1 is not a pre-requisite to installing 3.2.2, but for net distribution I will concede that diff's to previous PatchLevels are smaller, and therefore more acceptable. You then automatically know that you will need to find 3.2.1 and 3.2.2 before you can apply 3.2.3 to your copy of 3.2. You also know that if you can't get 3.2, you may as well hit the 'n' key. Dates are worthless unless you like to issue full releases every time somebody thinks adding a couple of widget keys would be neat-o. If you miss just one non-cumulative patch, you're hosed. (You're hosed in the PatchLevel situation described above, too, but at least you know it. :-) Having cumulative Revisions keeps the full-source releases down. Date-based patch identification prevents using an intelligent system. And adding a revision into the middle of the ID such as mm/dd/yy-rev-patch is just another way of restating the above while still hiding the history of the code. I realize that this may require the distributor and/or author of changes to code to actually keep track of what's been done. At least everyone who receives the code won't have to have perfect memories. -j -- J. Deters - jad@dayton.DHDSC.MN.ORG john@jaded.DHDSC.MN.ORG