Re: LYNX-DEV Update code and patches "RFC" :)

[Bill Kearney]

On Sun, 20 Oct 1996, Drazen Kacar wrote:
> The point is that you don't change version number just like that. These new
> features are not enough to convince your average sysop to comile Lynx again,
> and constantly upgrading version number might be counterproductive in sense
> that people will not pay attention when the really new version emerges.
> 
> However, it is necessary to have stable source for the development and I'm
> proposing releasing of patch levels primarily intended for the developers.
> Lynx with the composite patch could be named 2.6PL1 (and it would still
> output 2.6 in user-agent header). As soon as some new patch stabilizes, patch
> level increases by one. PL patches should be archived and made against the
> last official version, currently 2.6. All new patches should be made against
> the last PL version. In case the new patch does not change any of the files
> affected by the current PL patch, the PL version increases, but the old PL
> patch needs not to be archived.

I find it really, really annoying that the command line -version function
doesn't report the patch level.  I suppose leaving it at 2.6 in the
user-agent header might be acceptable but it's a valuable to be able to
get that info.  I've not looked into how the code deals with it but
something should be done.

As for the 'sanctity'  of the version number, get over it.  It's a very
common practive to use 3 digits.  Either that or the patch level reporting
found in stuff like perl.  

The recent flurry of mail here regarding the patches has been interesting.
The one thing it's shown is to NOT just use diffs as they emerge.  Wait a
day, it'll change.  <grin>

Bill

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;