Now that the new libFLAC interface has stabilized, I'm wondering if I should put out one more source release before 1.0? Or is it enough just to have you guys look it over? Binary compatibility should be easier to maintain now since 1) there are no structures passed or altered and 2) the constructors set reasonable defaults so that when parameters are added/ changed/deleted there should be a minimum of code changes for libFLAC users. The current code is still passing the test suite fine so I don't see any other holdups before 1.0. Some of the maybes on the post-1.0 list are: - fix windows piping (if possible) - variable blocksize encoding - auto-alignment of multi-wav encode on sector boundaries - CUESHEET metadata block Josh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
> In 1.0, don't forget to set the soname version in > src/libFLAC/Makefile.am like > so: > > libFLAC_la_LDFLAGS = -version-info 1:0:0Done. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
On Tue, Jun 19, 2001 at 05:10:58PM -0700, Josh Coalson wrote:> Now that the new libFLAC interface has stabilized, I'm wondering > if I should put out one more source release before 1.0? Or is > it enough just to have you guys look it over? Binary > compatibility should be easier to maintain now since 1) there > are no structures passed or altered and 2) the constructors > set reasonable defaults so that when parameters are added/ > changed/deleted there should be a minimum of code changes > for libFLAC users.In 1.0, don't forget to set the soname version in src/libFLAC/Makefile.am like so: libFLAC_la_LDFLAGS = -version-info 1:0:0 Then you can start changing the version to reflect binary compatibility changes (see the libtool docs, under "Updating version info" for more info). -- - mdz