[nas] Re: Silly versioning conflicts

[Jon Trulson]

On Sun, 10 Dec 2000, Steve McIntyre wrote:

> Date: Sun, 10 Dec 2000 20:06:20 +0000
> From: Steve McIntyre <stevem at chiark.greenend.org.uk>
> To: Jon Trulson <jon at radscan.com>
> Cc: nas at radscan.com
> Subject: Re: BOUNCE nas at radscan.com:     Admin request of type
>     /^\s*config\b/i at line 7 (fwd)
> 
> On Sun, Dec 10, 2000 at 12:25:30PM -0700, Jon Trulson wrote:
> >
[...]

> 
> >	What I do in the current version is use 2.x as the protocol level
> >that the server reports (which it does).  The library version reflects the
> >current NAS distribution, and will reflect updates to the library, but
> >not to the protocol.  A seperation of some sort between library and
> >protocol revisions seems wise...  
> >
> >	A argument could be made for doing it either way - I'd like to see
> >opinion on this.
> 
> It's a good question. Is the API of the library likely to change in
> any major fashion without the protocol changing? I'd guess it might,
> so the two should probably be separated. My main concern is that the
> major version of the library just went _backwards_, even though (I
> hope) the new library should be binary-compatible with the old.
> 

	The library API is extremely unlikely to change in an
incompatible way.  All of the changes I've incorporated or provided for
libaudio have always been fixes to the build or to correct bugs.  The
current 1.4 library, API-wise, is completely binary compatible to anything
written for 1.2*.

	The protocol version (2.2) itself has never been changed to my
knowlege since the 1.2 release.

> What might be nice is a new release number - jump from 1.4.1 to
> 2.0. Then we can unify the library version number with the NAS version
> again...
> 

	;-) Yeah, but then all those nice packages built with 1.x shared
objects over the last year or so will break hehe.

	Perhaps it is time to sync the release version and libaudio to
2.0, with the understanding that the libaudio and server protocol
revisions are likely to diverge after that...

	Thoughts anyone?

> >	How soon until you update the debian package?  I have a couple
> >fixes that should go in there, and now might be a good time to settle the
> >versioning issue as well.
> 
> I've got Erik Inge Bolso's patch for 2 channels (not 3!) applied, and
	
	I've got that too, and some additional OS support.

> I'm basically happy now to make a package and release it. I've had to
> put a couple of minor things back in from the previous package, but
> nothing major. It's all stuff that should apply cleanly on top of any
> other changes you have...

	The main 'serious' fix I have is in audio/soundlib.c - it corrects
a problem whereby clients would hang if the element Import size matched
the internally computed buffer size of a flow.  If you've ever had certain
sized audio files hang auplay, then you might want this.

	I will put together a development release (1.4.1a) that contains
these and other fixes.  I'll wait on the versioning issue until we know
what we should do. ;-)

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
Free Mars!