Hmm. The new scheme is far more regular, allows for a much simpler (read: “less fragile”) implementation, and mimics what we’ll have with the new file format in 6.0.
Can one of you say more about the issues it’s causing? The same data is being stored, so I don’t understand how it could create more noise on github? (I can see how the testscripts would need to be modified, but that’s not impossible is it?)
In the old scheme we had three flavours:
1) a lib alias (datasheet in alias record)
2) a lib alias with the root flag set (datasheet in field)
3) a component (datasheet in field)
The new scheme is simplified to two flavours:
1) a lib alias (datasheet in alias record)
2) a component (datasheet in field)
Cheers,
Jeff.
On 20 Nov 2018, at 23:55, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
It appears that this has indeed changed which has bitten me on my last
two symbol library pull requests. Had to manually edit the library and
document files so the root symbol datasheet was correct. We need to
change it back to the previous behavior.
On 11/20/2018 6:12 PM, Rene Pöschl wrote:
Is it possible that the datasheet field has been moved to the lib file
in the current nightly builds? That would break our testscripts and
create unnecessary noise on github. I thought the solution (for v5) has
been that the field of the lib file is filled with the one from the dcm
file if it is left empty. However it seems one can not fill the dcm file
version for a symbol that is not an alias.
_______________________________________________
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
_______________________________________________
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
