kicad-lib-committers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hi,

I started to package the updated packages due the tagged KiCad 5.1.6
release and started alphabetically with the footprints as this is the
first directory locally.

More by an accident I noticed that the directory
Connector_Multicomp.pretty is now empty. Digging into the reason behind
that I can see that the whole content of this folder has moved into
Connector_IDC.pretty.

I see there multiple issues here.

1. For me this is a breakage (again) of the rule no changes within the
stable release cycle on the user side that can break user projects and
workflows.
Compared to a classical C/C++ library would this be a removal of a
public symbol without an wrapper for backward compatibility, means an
API/ABI break which requires a increasing of the ABI version.

2. The default footprint table (fp-lib-table) within the tagged 5.1.6
tree is still referencing the old folder so user get this installed as
the default base for their footprint library table if they install a new
KiCad version or enforce a new default table.

> $ git grep -n Multicomp fp-lib-table
> fp-lib-table:28:  (lib (name Connector_Multicomp)(type KiCad)(uri ${KISYSMOD}/Connector_Multicomp.pretty)(options "")(descr "Multicomp connector foottprints"))

Keeping that entry makes no sense to me if the folder is now empty.

3. KiCad still has no internal mechanism to handle such removals within
the user space to adjust the local footptint table. Package
installations / removal doesn't touch or modify any user specific
configuration files so manual interaction from the user is needed to
adjust such cases.
Adding such an feature is not the responsibility of the library
maintainers of course, but makes such changes more difficult and
problematic within a stable release cycle. (And of course I don't want
to blame any one here!)

4. I haven't found a README or otherwise announcement about this change.
Also the commit message f764afb in kicad-footprints is rather short and
not explaining to me.

This all did already happen previously in 2017 in the releases of 4.0.5
and 4.0.7. At least two bug reports within Debian did happen due these
changes as this was leading to a breakage on the user side and also
leading to bad user experience.

https://bugs.debian.org/859409
https://bugs.debian.org/860093

In the past "we" solved the issues by adding symlinks from the old to
the new containing folder. Currently I'm undecided what to do here in
this new case.

Anyhow, please don't do such changes within a stable release cycle! It's
o.k. to do such things within major version bumps (as at some time it
must happen) but not within an increased *micro* version!
People do not expect such changes. And the majority of user isn't
following the development of KiCad itself or the libraries in deep! Keep
that in mind please. Thanks.

-- 
Regards
Carsten Schoenert