From xemacs-m  Fri Apr  4 04:46:08 1997
Received: from pallas.spacetec.no (pallas.spacetec.no [192.51.5.92])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id EAA13426
	for <xemacs-beta@xemacs.org>; Fri, 4 Apr 1997 04:46:06 -0600 (CST)
Received: (from tor@localhost) by pallas.spacetec.no (8.7.1/8.7.1) id MAA01185 for xemacs-beta@xemacs.org; Fri, 4 Apr 1997 12:46:56 +0200
Message-Id: <199704041046.MAA01185@pallas.spacetec.no>
From: tor@spacetec.no (Tor Arntsen)
Date: Fri, 4 Apr 1997 12:46:55 +0200
In-Reply-To: Vinnie Shelton  <shelton@icd.teradyne.com>
       "Re: 19.15 future" (Apr  3, 19:58)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: xemacs-beta@xemacs.org (XEmacs Beta List)
Subject: Re: 19.15 future

On Apr 3, 19:58, Vinnie Shelton wrote:
>David> This sounds good.  But we need to make sure that the ``version'' says
>David> something about the patchlevel, or else handling bug/crash reports will
>David> just get out of control.
>
>
>Hmmm.  This is a good point - one I should have thought of before.
>The same complaint can be made about the patches themselves, of
>course.  My plan had been for the bi-weekly patched source tarball to be
>*exactly* the sum of applying the patches on the page to a virgin
>19.15 dist.  Perhaps I should just include a version#-du-jour
>(semaine?) patch.
>
>More thoughts/suggestions?

If the tarball (always) is the sum of a virgin 19.15 and all the patches, 
then I suggest that you make the release number from the number of patches --
e.g. 19.15.p12 would be 19.15 + the twelve patches available so far.

Then you should also number the patches (as they appear on the web page),
so that someone could still refer to 'my XEmacs which is 19.15 + 
patch 1 & 3'.
(although I think such reports could quickly become a nightmare anyway :-)

Tor

