Closed poeschlr closed 5 years ago
@evanshultz, @Ratfink, @jkriege2, @Shackmeister How strict have you guys been with avoiding merging stuff that would break existing projects? If we have been strict enough then we can include an updated library into the next bugfix release. Otherwise that release will continue using the original version 5 release (Meaning no bugfixes and no new additions will make it into kicad until version 6 is released.)
My intent was to be as strict as described in this mailing list message. Could you read it and tell me if we to the best of our knowledge fulfill the promises given in it? https://lists.launchpad.net/kicad-developers/msg37312.html
While I haven't checked anything, I don't recall any major changes off the top of my head. There has been a lot added and fixed, but it's all incremental in my recollection. I believe any breaking changes should be minor.
I plan on writting a script that will give us a list of symbols that have design breaking changes. This list should allow us to make an informed decision.
I found we have the following design breaking changes made in the symbol lib since the 5.0.0 tag
Deleted or renamed symbols:
Symbols with moved, renumbered or removed pins:
Symbols where only NC pins have been touched (most likely moved onto the part outline. These changes should definetely be ok):
Driver_FET.lib:IR2106 wasn't actually deleted, it was turned into an alias of Driver_FET.lib:IR2101 in d54589d82740b3bf5face204da2b548645abeaae.
Oh. Hm that means my script needs a bit more power. (Might also need to check for aliases that are no longer aliases.)
Release is comming. How are we doing with this? What needs to be done?
Run the testscript i wrote, ask over at the mailing list if the changes are within acceptable limits. If yes tag the current master with 5.0.1. If not no new tag should be made in my opineon. But the packagers might not like it that way as they would need to change their scripts to still get the tag for 5.0.0 for the libraries.
Edit: My testscript requires you to have two copies of the lib. One that is on 5.0.0 and one that is on current master. It reports changed pin positions and also deleted (or renamed) symbols.
Worst case scenario the tag for 5.0.1 can be set to point to the 5.0.0 commit in order to avoid changes for packagers. Little bit better scenario we can point to the previous commit that first breaks compatibility.
So what is going to the included with 5.0.1? It's supposed to be tagged in a matter of hours (https://lists.launchpad.net/kicad-developers/msg37819.html).
I know you're going to check out the delta changes, Rene.
The only outstanding PR I see as important to merge is https://github.com/KiCad/kicad-symbols/pull/1044 since a user reported an error in the library and destroyed a part due to it. Otherwise, and since that one isn't critical, merging it and tagging 5.0.1 or leaving 5.0.0 is OK with me.
Fix merged Edit: Wrong issue
I ran my test script again. A few more symbols now have incompatible changes. (Edit: a bit inflated as i now also included aliases in the list.)
Full report file: report.txt There are 1183 changed symbols that are still compatible with earlier releases There are 355 new symbols
Now a list of the incompatible changes:
Pins have been moved, renumbered or removed in the following symbols:
Normal pins ok but NC pins have been moved, renumbered or removed in the following symbol:
Removed or renamed have been the following symbols:
Renamed (bugfix, added correct suffix to indicate which package the symbol uses. PR: https://github.com/KiCad/kicad-symbols/pull/826):
Wayne gave the ok so i will tag the current state of the lib as 5.0.1. See: https://lists.launchpad.net/kicad-developers/msg37835.html
https://lists.launchpad.net/kicad-developers/msg37283.html