Avoiding breaking changes can be handled by increasing the testing surface, kicad-python has testing, but it's not currently being executed on every commit.
While the native bindings are being tested on every commit by the kicad-ci [1] [2]: Increasing the test surface could be useful in many ways: 1) Better quality 2) Avoiding breaking changes to API users 3) Tests can serve as a documentation point and contract on what we expose, and how we do it. If you need to change a test in a backwards incompatible way: it's time to write a notice (in other projects where I work we document every breaking change to APIs, and try to provide a deprecation warning and support for 1 stable release (where that's possible). May be it's time to start increasing the testing surface. [1] https://git.launchpad.net/kicad/tree/qa/testcases [2] http://ci.kicad-pcb.org/view/KiCad%20builds/job/kicad-qa/2001/console (look for test.py) On Mon, Sep 19, 2016 at 4:20 PM, Wayne Stambaugh <[email protected]> wrote: > On 9/19/2016 9:52 AM, Michael Steinberg wrote: >> Hello Wayne, Torsten & All, >> >> >> Am 19.09.2016 um 15:17 schrieb Wayne Stambaugh: >>> I'm going to make an executive decision here so this doesn't drag on. >>> In short, swig stays. Any other python bindings would either be on top >>> of or along side current swig bindings. Swig is a valid tool for >>> generating scripting language bindings. Lots of other projects use it >>> with great success so it can't be all bad. We already have a large >>> investment of time in the current swig bindings along with lots of >>> project and user scripts that use them. I do not want to discard that >>> investment of time and effort. If anyone feels so inclined to write >>> some other python interface, there cannot be namespace clashes with the >>> current python bindings. >>> >>> On 9/19/2016 5:49 AM, "Torsten Hüter" wrote: >>>> Hi Tom & Michael, >>>> I'm using the scripting interface quite often and had never that much >>>> trouble with it. >>>> The currently missing std::unique_ptr is not an argument, it is still >>>> possible to use it, see >>>> http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig >>>> >>>> I'm quite sure that in the future almost any C++ 11 features will be >>>> supported by swig. >>>> Pybind is - as you have written - generatorless, in my opinion this is >>>> exactly the downside. >>>> You have to write wrappers yourself, while with swig you're simply >>>> including headers in the *.i files. >>>> >> >> I'm fine with staying with SWIG (See I also added it in the points of >> possible options twice). But still I'm left with contradicting >> statements about the stability of the blobs the current SWIG headers >> spit out. While Wayne's main point is that we cannot break existing >> scripts, Thorsten says that is no problem at all. If refactoring and >> exporting it like usual is no problem, then I have nothing left to >> argument about, because the initial problem I was addressing was >> non-existant to begin with (I'd like that, because it means no work!). >> If that is not the case, just saying SWIG stays is fixing the >> technicality, but not the specified API concerns imho. >> >> Michael >> > > I'm not suggesting that we will always have absolute api stability. I'm > not sure that is even realistic. I can't think of a project of any > significance that's been around for any length of time who's api didn't > break something at some point. Yes, event the C language had it's > moments way back when. There may be occasions when we have to break > existing behavior. However, most of the low level objects in pcbnew > have not changed significantly over the last few years. We've added new > functions to the api but we haven't made major changes to the existing > api. I don't remember anyone ever complaining about this but I may have > missed it. > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
