Hi, Rene.
Thanks for bringing this up. I've never liked hidden power pins. In my
opinion, the python philosophy applies here too: "Explicit is better
than implicit."
How many libraries will need this?
I'm asking because, if we went for option 3 (or 2), will we end up
with a lot of nearly identical duplicated libraries? That can be very
confusing for users and for maintaining the GitHub libraries (e.g.
getting pull requests for the old libraries instead of the new ones,
etc.).
And at some point we would need to get rid of the old ones anyway not
to carry them forever, won't we?
I'm wondering whether we can for option 1 if we evaluate what the
behaviour would be regarding ERC, symbol rescue, etc.
Thanks,
Diego
On Tue, Nov 6, 2018 at 9:42 PM Rene Pöschl <poeschlr@xxxxxxxxx
<mailto:poeschlr@xxxxxxxxx>> wrote:
Hi all,
Sadly we did not come around to fix all symbols before the v5
release.
We now seem to have a volunteer who would be prepared to fix these
symbols.
There is a catch though. Whatever we do to fix this it will break
designs that use the old symbols right now.
So we have a few options:
- 1 - Change the symbols inside the library and inform the users
about
this fix. (Will break current designs as the power pins will no
longer
be connected automatically. This after all is the point of the
fix. Not
sure if rescue is reliable enought to chatch that. ERC might also not
complain if we put the power pins onto a separate unit.)
- 2 - Add a separate library that holds the fixed symbols, keep
the old
one but remove it from the template library table. This means no
designs
are borken as old users do not get the new lib added without an
explicit
action on their part.
- 3 - Rename the library before fixing it. add the new lib to the lib
table. This would still break designs. (But in a different way. In
this
case the symbol might simply not be found. This is something that the
rescue stuff should deal with.) In addition users will get an error
message when starting eeschema or the symbol editor that alerts them
about a missing file. (So if we make an announcement that includes
the
error message they should find it when they google for it.)
My personal vote would be for option 3.
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help : https://help.launchpad.net/ListHelp
