On Thursday 12 January 2006 11:04 pm, Derek Atkins wrote: > It will, by default, use internal qof unless you configure with > --enable-qof. The idea is that gnucash svn shouldn't break if changes were > made to internal qof that change the API from external qof.. > > You, Neil, can still test with --enable-qof.. And end users can also test > with --enable-qof if they so wish..
Understandable. > The plan in my head is that once we cut the pre-2.0 releases we can swap > the option the other way so it defaults to looking for external qof. > I have no trust that 2.0 will happily use 0.6.0.. With Chris' changes, it will have to be at least 0.6.2 - unless I can make his changes backwards compatible. This will still be libqof1, backwards compatible with 0.6.0 for those applications (like gnotime) that don't use the added functions. pilot-qof is already dependent on libqof1 >= 0.6.1 as it uses some date manipulation functions added to libqof at 0.6.1. > It's quite possible > the API will get extended in 0.6.2 or 0.6.3 and that gnucash will require > that minimum... Is that a problem? (It certainly will not be a problem for Debian or Fink and possibly Fedora.) > Note that adding APIs does not require a library major > version bump. Only CHANGING APIs requires a version bump. Yes, I know. libqof1 will remain compatible until such time as libqof2 is available. It's all documented at the QOF doxygen page: http://qof.sourceforge.net/doxy/ libqof has had a *revision* bump (as has QSF) at 0.6.1 - as it should because the source has changed. I implemented this in configure.in at r12299. A major version jump will not occur until libqof2 which will not be backwards compatibility with libqof1. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgproR41Ryaw1.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
