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