From: David B. <dav...@gm...> - 2010-11-30 04:32:30
|
Hi Brendan, On Mon, Nov 29, 2010 at 9:15 PM, Brendan Luchen <bm...@ri...> wrote: > We will have to be careful not to let newer builds break with somewhat older > package-managerized versions of t4k_common. I was guilty of this at times as > I migrated TuxMath over--committing code in TuxMath that depended on > t4k_common code that only existed on my local copy and broke when using the > t4k_common head. > Cheers, > Brendan Yes, there is more code that should go into t4k_common (convert_utf, linebreak, scandir/alphasort, off the top of my head). When we move this out of tuxmath, the corresponding version of t4k_common will be needed. Older versions of tuxmath ought to build with newer versions of t4k_common, but the reverse won't be true. I think we can keep this straight if we follow the libtool version numbering scheme: Major number - changes when library removes part of interface (breaks backward compatibility) Minor number - changes when additional features added, nothing removed (still compatible) Micro number - changes when implementation only changed, same interface. (at least that's how I understand it) David David |