In most cases you would not want to have you metadata messed up, just because KiCad finds another version of your symbol.
However, what one could dream about is a tool that would let you search out for instance all capacitors with a value of 100nF and let you update all the different metadata fields for those symbols. (A nice feature could be that it would only update those fields that were edited,leaving the rest alone.) This would make it easier to enter metadata that can be used for BOM creation.
Currently the most efficient strategy to accomplish the same end result is to create āatomicā parts for the most used symbols, so that the information is already there when inserted into the schematic.
I always have atomic parts with real world part numbers.
And kicad will not mess up my local library (design local library).
Beacuse updates should be done at user request only.
Right click the part in the schematic and select from:
1 update this part
2 update all of this part in entire schematic.
3 update every part in schematic
This generic part problem with 100nf as part no instead of a real part # is a dead end for kicad.
You get up and about quickly but in the end professional needs cannot be catered for.
One could at least hope for an understanding but the way of thinking is so different that I notice people donāt even understand what I try to explain.
Not being able to update the parts (unique atomic parts) in your local design library with the outside version of that exact atomic part is a huge problem.
To delete your part in the schematic and put in the exact same part again is the only way to get your meta data/text fields refreshed.
Itās not something one can live with long term.
Thanks Rene, I had not fully discovered the table editor, I thought it was just for displaying an overview, but discovered now one can update the fields. However I found the edit to be a bit shaky. Sometime it would take a double click, other time not. And if I edit and apply changes to one field the next symbol I click on will also get that value, so may be some more work is needed there (using unsigned Dec. 8 Windows nightly).
I do think see what Nicholas is after though, One has created a schematic, without much metadate or with incorrect ones in it and now you want to use a pre-existing āmolecularā part to get that metadata for BOM/ordering info updated instead of retyping it in again.
For my molecular parts, I have symbol names like R_1206_10K_RC1206FR-0710K and with all needed footprint and ordering info defined. On insertion I change the value to 10K. The part will still reference R_1206_10K_RC1206FR-0710K in my custom library, it is just the displayed value that is changed. If I look at its properties all the original info for that part is displayed and ready for use in Pcbnew or creating a BOM.
I see now that a later nightly carries the possibilty to read in the fields from the lib when you open the properties dialog in eeschema
this is such a great step forward in the right direction.
now you should also be given the possibility within same properties dialogue to do this on all components of same value, not only the one you opened the prop dialogue on
unfortunately when you read in text fields that was not placed before in the schematic they end up far away from the component.
Some of use like to live dangerously . Actually if there is a time one should go for the nightly that is in the pre-release period after the feature freeze (which is already in effect) to help developers pinpoint as many bugs as possible before the final V5 release.
Some precautions are vise though: frequent backups of everything of course, keeping up to date on what is going on on the bug tracker and the KiCad code list with repect to recent changes (I like this view ), and perhaps above all (that probably applies to any version in use now): Not to rely on referencing the official kicad libraries directly even when stored locally, or at least not at time of conversion to the new sym-lib-table format, as they are being reorganized and one could risk soon obsolete library names to get hard coded into the project files at conversion. And of course the risk might not be worth taking for time critical projects in the final stages. One should not go into this expecting that everything works perfectly.
I usually do this kind of testing with a separate installation in a VM, but right now I have reorganized my custom library and successfully converted all my projects to the new sym-lib-table format for my main installation after the initial testing period in a VM (only relying on two libraries: my own custom library and the official power library). I am really impressed with how responsive the developers are to the bug reports. Also one should not overlook the fact that the nighties have many bugs fixed that have existed for a long time, not only in the later versions.
There has to be a way of manually copying an unsigned build onto the official server.
There have been several significant changes such as the threaded zone filling, which really need mass testing
The reason it would be important for me:
Ensuring integrity. (Has somebody outside the kicad developers tempered with the installer? The package could even be tempered with in transit. Downloading unsigned stuff is a big security risk.) This of course only works if the code signing procedure is itself secure.
I am not sure if this will impact the v5 release. The latest update from wayne was that he plans to split the v5 branch around Christmas, with the v5 release planned for the first week of februar. (But he mentioned that this might be a bit optimistic.)
You could ask over at the mailing list if you want clarification. (I am not involved in any of this.)
If history is a guide, the release process for v4 took from about design freeze in March to final release in December 2015, and I donāt see any reason why v5 would be any different. That would suggest final v5 will not be until August 2018.
I donāt see the process taking that long as Nightlies have been fairly clean for a long time. Once the library reshuffle is finished a 5.0.0 is possible.
There is also a lot of pressure to avoid 4.0.8, 4.0.9 etc
. Actually if there is a time one should go for the nightly that is in the pre-release period after the feature freeze (which is already in effect) to help developers pinpoint as many bugs as possible before the final V5 release.
I only noticed the second time I read it: