kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <majopela@xxxxxxxxxx>]

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 <stambaughw@xxxxxxxxx> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp