Here we are…
BTW I do use DRC. The biggest thing is the smallest reason; moving all of my silkscreen text off of pads. I do get a lot of overlapping silkscreen component outlines. I use a small-ish 0805 footprint for 0603 chips. Allowing the silkscreen outlines to overlap does not seem to be a real problem.
Awesome 
now how long to isolate and ignore them so you had a clean sheet of all green ? I’m sure not long, then you would expect a clean bill of health every time. So if an error did occur its one you haven’t seen before and can fix or add to the list of ignores. A cumulative advantage I see but thanks for playing along, you’re a good sport 
My cousin worked at Litton and they had it in the 70’s
I first used PC CAD and PCB software in the early to mid '80s
Getting nearly 300 error where there were none on 7.x.x on a board that’s been working flawlessly for a couple of years says “This software is screwed up!” when no other CAE package in 40 years has ever come close to requiring hours to negate.
IF this was known - and I can’t see how it wouldn’t be - there should be a LARGE warning in the docs and installer that ERC is radically different AND documentation provided listing the changes implemented.
More likely that your original schematic was riddled with errors that the earlier version didn’t catch.
Now that the newer version is more strict, it seems like it’s “creating” errors, when it really is just catching a bunch of poor design decisions.
This is extremely common in software development, where code that used to compile perfectly suddenly generates scads of errors in a newer complier.
Me thinks not.
It’s a Valve [Tube] Tester, it’s worked flawlessly for two years and errors @ 450VDC tend to make things go POOF PDQ 
Sometimes it’s riddled with just a few types of errors and the hundreds of reports are just multiple instances.
I had a circuit that was last worked on in v7 I think and when I opened it up, I got tens of errors and warnings. But it boiled down two really. One was connections off grid. Ctrl-A followed by Align to Grid fixed that. The others were symbol different from library. Since there were all standard symbols, I elected to update symbols from library. And just like that everything came clean.
I imagine a faulty power symbol could cause hundreds of errors. Dennisch has already posted fixes but reading that is not as much “fun” as whinging, I guess.
There are similar situations in software. For example if you were to hand a C program with classic function declaration symtax, it would elicit heaps of errors from an ANSI-C compiler. Running the program to convert the function prototypes will fix that in one go.
Hi @IEales ,
I’ve just been re-reading this thread. Wayyyyy up top you write:
Then a couple of posts down , you state:
If you are using symbols created maybe six years ago (Kicad 4 era?), it is not at all surprising that they fail the current ERC.
I’d already fixed the schematic by the time the fix was returned. While I appreciate the effort, a list of fault causes rather than a ‘fixed’ schematic would have been be far more instructive. I diffed the out and returned text files to see what was done.
That being said, some of the rules are nonsense for other than a limited scope and the ‘fixes’ are bandaids that could fail in the next iteration.
Some of the additional requirements for an ‘error free’ schematic fly in the face of “Keep It Simple, Sonny”
V5 in early 2019.
V8 installer could have had a dialog stating major changes to symbols, power rules and DEI silliness scotching every _Male / _Female symbol in existence.
Had I ever done something like that, at the very least the installer would have a list of obsoleted parts and if I had the resources, a utility to update them!
Since the files are text, bog simple for most cases w RegEx.
A handful of faults is easier to rectify than hundreds x the user base!
That being said, some of the rules are nonsense for other than a limited scope and the ‘fixes’ are bandaids that could fail in the next iteration.
You as a designer are responsible for adjusting the violation severity for all ERC checks. You can’t delegate this task and simply blame kicad. While you find some ERC checks nonsense there are other users who find them useful. Most of these checks were implemented because someone had a usecase and asked for the check.
So if you find some ERC checks nonsense, just disable the relevant check (File->schematic setup–>Electrical rules–>violation severity). Or don’t run the ERC at all.
As development goes on you will find enhancements to the ERC/DRC on every major kicad version. If you don’t like the new checks: switch them off.
A better solution would be ignore this error at this point once the connectivity is verified.
Blanket removal trades inconvenience for potential disaster.
A better solution is to understand the features offered by the latest ERC and use them to your best advantage.
All this whining about the tools checking “too much” is just people trying to blame the software for their own failures.