We can also put version number in library and footprint like gEDA do. 
This way, Kicad can update symbol when minor change happen and use cache when 
major change occur.

http://wiki.geda-project.org/geda:master_attributes_list 
<http://wiki.geda-project.org/geda:master_attributes_list> :

symversion <>
The symversion= attribute is used to version the contents of symbols. Because 
symbols are, by default, referenced from the schematic and not embedded within 
it, problems can occur in a schematic using a particular symbol if that symbol 
file is modified. For instance, if pins are moved in the symbol, the schematic 
net lines will no longer connect to the correct pins. The symversion= attribute 
allows tracking such breaking changes to symbols and notifying the user of 
potential problems when a schematic is loaded.

This attribute is optional, but if present it must take the following form:

major.minor

where major and minor are integers. The major number is incremented when a 
change is made to a symbol that might break an existing schematic using the 
prior version of symbol when the new version is introduced. The minor number is 
only incremented when a minor change is made (a change that cannot break an 
existing schematic, such as cosmetic changes while retaining structure such as 
location of the pins).

If this attribute is inside a symbol and that symbol is placed onto a 
schematic, the symversion= attribute will be automatically “promoted”, causing 
a copy of the symversion=M.N attribute to be stored on the symbol instance in 
the schematic itself. When a symbol is loaded from disk, the value of the 
symversion= inside the symbol file (if any) and the symversion value attached 
to the symbol instance on the schematic are compared. If the values differ, 
then libgeda will output a warning message (for minor version changes) or an 
error message (for major version changes).

This attribute should normally be made invisible when placed inside a symbol 
file. This attribute is always promoted when it is found inside a symbol during 
component placement. Users should not attach this attribute manually to 
instantiated symbols in a schematic.

Examples:

symversion=1.1

symversion=2.0

___________________________

Samuel Dolt


> Le 25 avr. 2015 à 04:48, Carl Poirier <[email protected]> a écrit :
> 
> What if we have a "Never show on startup" checkbox LOL.
> 
> No seriously, this indeed would be great for not only libraries but anything 
> else. The website will need a section for the news as well, which currently 
> from what I see doesn't have.
> 
> On Fri, Apr 24, 2015 at 10:38 PM, Adam Wolf <[email protected] 
> <mailto:[email protected]>> wrote:
> Carl and other library folks,
> 
> I understand you had to make the change, and I'm certain it took hard work to 
> make everything match, and I'm glad that the libraries are better now, but I 
> hate the fact that many, many users will never be notified of this 
> board-breaking change, and we have absolutely no way of notifying them.
> 
> Rather than make a github-plugin specific change that will only alert users 
> about changes in footprints, I think we should see if we can quickly code a 
> dialog that checks a location on kicad-pcb.org <http://kicad-pcb.org/> for 
> news, and display it on KiCad startup by default if it has changed.  I would 
> like to get this in before the stable release, but I know we're already in 
> feature freeze.  Wayne, what do you think?
> 
> Adam Wolf
> Cofounder and Engineer
> Wayne and Layne, LLC
> 
> On Fri, Apr 24, 2015 at 9:25 PM, Carl Poirier <[email protected] 
> <mailto:[email protected]>> wrote:
> Hi Adam,
> 
> Indeed, those who want to be sure nothing changes until they want so are 
> better to make a local copy. With the new Footprint Libraries Wizard, users 
> are just a few clicks away from it with the checkbox "Save a local copy to". 
> Using the libraries directly from Github is bleeding-edge, but as you said 
> the problem arises from the fact that we have symbols installed locally and 
> footprints fetched from Github. If both are handled the same way, either way 
> it is, it will be fine. And again this causes problems only for aspects of 
> libraries that have to be in sync - such as pin numbers. The other things 
> that have to be in sync are the 3D models. That's why many folks, including 
> me, have suggested 
> <https://lists.launchpad.net/kicad-developers/msg14793.html> to move the 3D 
> model inside the .pretty library. Maybe it could be done elegantly, but 
> unfortunately I'm not the one who has enough time to put in this.
> 
> As for the other libraries, we're slowly getting to a stable and consistent 
> state. Besides eradicating the special.lib library, I can't think of another 
> disruptive change that will happen soon. I'm not saying there will be none, 
> just that there are none planned. We go as our time permits.
> 
> As for why people would use KiCad's libraries, I'd say because they can be 
> assured at least two librarians go over a suggested change to iron out 
> errors. Also because new parts are constantly thrown into the mix as well so 
> the libraries are getting more complete over time. As for the quality of the 
> pre-github era libraries, nothing can be vouched. We're fixing things as we 
> find them. What's great is that with Github, it's very easy for those people 
> in doubt about KiCad's libraries to contribute and make them better if they 
> think there is room for it.
> 
> I should have warned in advance here for this change specifically to make 
> sure everyone was aware. I should have not relied on the fact that no one 
> disagreed days ago about having disruptive changes in general. Besides that, 
> I'm not sure what more could have been done.
> 
> Regards,
> 
> Carl
> 
> On Fri, Apr 24, 2015 at 8:43 PM, Adam Wolf <[email protected] 
> <mailto:[email protected]>> wrote:
> Carl,
> 
> I have had multiple people contact me today saying, "Why would I ever use 
> KiCad's libraries again?"
> 
> I had no idea before your email today that diodes were going to change, and I 
> follow the dev list daily, and I'm the packager for the OS X nightlies.
> 
> We're in this together.  I don't have time to check yet another place for 
> KiCad changes.
> 
> After I think about this some more, I'm going to start another thread on what 
> this means for the OS X nightlies.  By having half the data burned in, and 
> half the data updated live, this is going to continue to happen.  People are 
> going to make bad boards, and if I would have bundled the footprints with the 
> nightlies and not made Github the default, this wouldn't have happened.
> 
> Most of the other packages are like this, right?
> 
> Adam Wolf
> 
> Cofounder and Engineer
> 
> Wayne and Layne, LLC
> 
> (resending from an email that can post to kicad-dev...)
> 
> 
> On Fri, Apr 24, 2015 at 7:42 PM, Adam Wolf <[email protected] 
> <mailto:[email protected]>> wrote:
> Carl,
> 
> I have had multiple people contact me today saying, "Why would I ever use 
> KiCad's libraries again?"
> 
> I had no idea before your email today that diodes were going to change, and I 
> follow the dev list daily, and I'm the packager for the OS X nightlies.
> 
> We're in this together.  I don't have time to check yet another place for 
> KiCad changes.
> 
> After I think about this some more, I'm going to start another thread on what 
> this means for the OS X nightlies.  By having half the data burned in, and 
> half the data updated live, this is going to continue to happen.  People are 
> going to make bad boards, and if I would have bundled the footprints with the 
> nightlies and not made Github the default, this wouldn't have happened.
> 
> Most of the other packages are like this, right?
> 
> Adam Wolf
> 
> Cofounder and Engineer
> 
> Wayne and Layne, LLC
> 
> On Apr 24, 2015 7:01 PM, "Carl Poirier" <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> Then you should have come by and discussed the matter on Github. The issues 
> and pull requests about the diodes had been open for a while now and open for 
> comments. To get updates in time about the changes proposed, I suggest you 
> watch this repository <https://github.com/KiCad/kicad-library>.
> 
> If you have suggestions for the next similar situation, I'm listening.
> 
> On Fri, Apr 24, 2015 at 7:55 PM, Garth Corral <[email protected] 
> <mailto:[email protected]>> wrote:
> I don’t object to what you’re doing, just how it’s being done.  You don’t 
> think this case is just a little bit special?  Last time things were pretty 
> obviously broken with the change, in this case they’re not.  You’ve swapped 
> out a symbol for something that’s basically the same except, oh, by the way, 
> all your diodes are reversed.  Am I misunderstanding this change?  Is this 
> not true?
> 
> Garth 
> 
>> On Apr 24, 2015, at 4:34 PM, Carl Poirier <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> KiCad's libraries were filled without any rules throughout time. All these 
>> changes are necessary to have something consistent. Kerusey Karyu warned 
>> people one month ago on the mailing list 
>> <https://lists.launchpad.net/kicad-developers/msg17476.html> that we were in 
>> the process of moving things around. No one complained. Now why when we take 
>> action people wake up all of a sudden?
>> 
>> The sooner we get things straight, the better it is. If we wait too much, it 
>> will be too late. Before issuing the stable release sounds like an 
>> appropriate moment to land the disruptive changes.
>> 
>> BTW, I'm about to eradicate the special.lib library, as planned for now over 
>> one month <https://github.com/KiCad/kicad-library/issues/153>, a great 
>> initiative taken by Kerusey.
>> 
>> Regards,
>> 
>> Carl
>> 
>> On Fri, Apr 24, 2015 at 7:21 PM, Garth Corral <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> This plan to deprecate the old diode type seems… uh... poorly thought out.  
>> Yanking these out from under everyone and every project in exiistence and 
>> then sending out a message that says, “hey, guess what I did?” doesn’t seem 
>> like the best way to handle this.  It is most certainly not the way to win 
>> converts to kicad.
>> 
>> 
>> Garth
>> 
>> 
>>> On Apr 24, 2015, at 2:31 PM, Carl Poirier <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> Thiadmer, your proposal would require to duplicate every .pretty repository 
>>> for every stable release. And I believe the schematics won't change because 
>>> of the cache.
>>> 
>>> Another solution would be to modify the github plugin to fetch a branch in 
>>> particular instead of the master. Then, we could create one branch in each 
>>> .pretty repository that would remain in the state at the time of the stable 
>>> release.
>>> 
>>> That, or we ship the stable release with local .pretty repositories as well.
>>> 
>>> On Fri, Apr 24, 2015 at 3:20 PM, Thiadmer Riemersma 
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> For the stable release, I would vote for backward compatibility: have 
>>> "deprecated" libraries with the diodes as they are right now (footprints + 
>>> symbols), plus "standards-compliant" libraries with the cathode at pin 1 
>>> and the anode at pin 2. It would not be good if old schematics change just 
>>> because they are loaded in a new version of KiCad.
>>> 
>>> 
>>> On Fri, Apr 24, 2015 at 7:31 PM, Carl Poirier <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> Maybe this could be implemented for the stable release.
>>> 
>>> On Fri, Apr 24, 2015 at 1:30 PM, Bob Gustafson <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> Sounds professional.
>>> 
>>> Bob G
>>> 
>>> 
>>> On 04/24/2015 12:24 PM, Adam Wolf wrote:
>>>> For future things like this, what do people think of a webview that pops 
>>>> up on startup after checking a site for alerts?
>>>> 
>>>> On Apr 24, 2015 12:14 PM, "Carl Poirier" <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> All installations need a local kicad-library, not just OS X. They are all 
>>>> in the same situation. The next OS X nightly will be good if you pull the 
>>>> latest kicad-libary for the build.             
>>>> 
>>>> Kerusey Karyu will announce the change on the users group on Yahoo to warn 
>>>> people. If anyone has an account and wants to forward my message before he 
>>>> does, feel free to do so.
>>>> 
>>>> On Fri, Apr 24, 2015 at 12:55 PM, Adam Wolf <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> Hmm.
>>>> 
>>>> So the OSX builds use Github by default for footprints, and have symbols 
>>>> "baked in" at build time.
>>>> 
>>>> Every OS X nightly build is going to produce bad boards, and there's no 
>>>> way to tell users to update or inform them about this change through the 
>>>> program at all.
>>>> 
>>>> I really wish I would have known about this earlier.
>>>> 
>>>> Adam Wolf
>>>> Cofounder and Engineer
>>>> Wayne and Layne
>>>> 
>>>> On Apr 24, 2015 11:42 AM, "Carl Poirier" <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> Hi folks,
>>>> 
>>>> This is simply to warn you that all diodes in KiCad's libraries have seen 
>>>> their pin numbers swapped. This is to be in line with most other software 
>>>> and the IPC standard as well, which states that cathode should be pin 1. 
>>>> This work is courtesy of the newest librarian, Ricardo Crudo.
>>>> 
>>>> If you are using Github libraries directly, the only thing you will have 
>>>> left to do is update your schematic libraries to the latest revision of 
>>>> https://github.com/KiCad/kicad-library 
>>>> <https://github.com/KiCad/kicad-library> before continuing your work. If 
>>>> you have a local copy of the footprint repositories, then when you are 
>>>> ready you will be able to pull the changes for both the schematic 
>>>> libraries and the affected footprint libraries:
>>>> 
>>>> 1. Diodes_SMD.pretty <https://github.com/KiCad/Diodes_SMD.pretty>
>>>> 2. Diodes_ThroughHole.pretty 
>>>> <https://github.com/KiCad/Diodes_ThroughHole.pretty>
>>>> 3. LEDs.pretty <https://github.com/KiCad/LEDs.pretty>
>>>> 
>>>> Thank you for your understanding and sorry for the inconvenience.
>>>> 
>>>> Carl Poirier
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/%7Ekicad-developers>
>>>> Post to     : [email protected] 
>>>> <mailto:[email protected]>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/%7Ekicad-developers>
>>>> More help   : https://help.launchpad.net/ListHelp 
>>>> <https://help.launchpad.net/ListHelp>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers>
>>>> Post to     : [email protected] 
>>>> <mailto:[email protected]>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers>
>>>> More help   : https://help.launchpad.net/ListHelp 
>>>> <https://help.launchpad.net/ListHelp>
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to     : [email protected] 
>>> <mailto:[email protected]>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to     : [email protected] 
>>> <mailto:[email protected]>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to     : [email protected] 
>>> <mailto:[email protected]>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to     : [email protected] 
>>> <mailto:[email protected]>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to     : [email protected] 
>> <mailto:[email protected]>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to     : [email protected] 
> <mailto:[email protected]>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>
> 
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : [email protected]
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to