On Sun, 23 Oct 2011, Paul Wise wrote: > > And with javascript libraries, there's no failure at build time, > > you only discover much later when something is not working... > This is the crux of the issue and it is not specific to JavaScript > libraries, anything that is interpreted has this issue. I'm pretty > sure I've seen API breakage in libraries implemented in Python for > example. > More automated and manual testing can help here I guess.
yeap -- in python world the situation is generally better because unittesting is easy and popular, so for nearly all python packages I maintain I introduce package build-time unittesting against all supported versions of Python. That helps A LOT to assure correct performance especially having heavy backporting in mind (we usually build nearly for all recent releases of debian and ubuntu within neuro.debian.net project). Sure thing not all projects have 100% unittest coverage, also problems some times go unnoticed if it is arch 'all' package while has some arch specific operations (I/O, byteswapping) which do not get picked up unless they get excercised by unittests of dependent modules with packages of arch 'any'... but altogether there testing is indispensable to verify compatibility of API and just general QA. So, if only we could provide relevant automated basic testing to those JS-dependent packages... -- =------------------------------------------------------------------= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111023165103.gc10...@onerussian.com