kicad-developers team mailing list archive

[Rene Pöschl <poeschlr@xxxxxxxxx>]

On 12/05/2020 09:40, Carsten Schoenert wrote:
> 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.
What is broken here? The old library folder is still there to ensure 
users do not get an error message. Footprints are embedded in the design 
files so no negative impact on old designs. The new footprints are 
vastly superior to the old ones so the tradeoff is simply worth it!
> 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.
Yes we could remove the entry but our CI script would complain -> so we 
decided to just have the empty lib it does not hurt anyone.
> 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!)
Well now you know why we keep the empty folder. (At least v5 does no 
longer crash with a missing lib.)
> 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.
The two bug reports you list again clearly show why we now keep the 
libraries as empty instead of removing them.