kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #18058
Re: UPDATE: Diode pins swapped in KiCad Libraries
See my reply to Adam about why this will not be necessary when the new
file format is complete.
On 4/25/2015 6:07 AM, Samuel Dolt wrote:
> 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 :
>
>
> 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 <carl.poirier.2@xxxxxxxxx
>> <mailto:carl.poirier.2@xxxxxxxxx>> 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
>> <adamwolf@xxxxxxxxxxxxxxxxxxxx <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>>
>> 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
>> <carl.poirier.2@xxxxxxxxx <mailto:carl.poirier.2@xxxxxxxxx>> 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
>> <adamwolf@xxxxxxxxxxxxxxxxxxxx
>> <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>> 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
>> <adamwwolf@xxxxxxxxx <mailto:adamwwolf@xxxxxxxxx>> 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"
>> <carl.poirier.2@xxxxxxxxx
>> <mailto:carl.poirier.2@xxxxxxxxx>> 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
>> <gcorral@xxxxxxxxx <mailto:gcorral@xxxxxxxxx>> 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
>>> <carl.poirier.2@xxxxxxxxx
>>> <mailto:carl.poirier.2@xxxxxxxxx>> 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
>>> <gcorral@xxxxxxxxx
>>> <mailto:gcorral@xxxxxxxxx>> 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 <carl.poirier.2@xxxxxxxxx
>>>> <mailto:carl.poirier.2@xxxxxxxxx>> 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
>>>> <thiadmer.riemersma@xxxxxxxxx
>>>> <mailto:thiadmer.riemersma@xxxxxxxxx>>
>>>> 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
>>>> <carl.poirier.2@xxxxxxxxx
>>>> <mailto:carl.poirier.2@xxxxxxxxx>>
>>>> wrote:
>>>>
>>>> Maybe this could be implemented
>>>> for the stable release.
>>>>
>>>> On Fri, Apr 24, 2015 at 1:30 PM,
>>>> Bob Gustafson <bobgus@xxxxxxx
>>>> <mailto:bobgus@xxxxxxx>> 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"
>>>>> <carl.poirier.2@xxxxxxxxx
>>>>> <mailto:carl.poirier.2@xxxxxxxxx>>
>>>>> 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
>>>>> <adamwolf@xxxxxxxxxxxxxxxxxxxx
>>>>> <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>>
>>>>> 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"
>>>>> <carl.poirier.2@xxxxxxxxx
>>>>> <mailto:carl.poirier.2@xxxxxxxxx>>
>>>>> 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 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 :
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list:
>>>> https://launchpad.net/~kicad-developers
>>>> Post to :
>>>> kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> Unsubscribe :
>>>> https://launchpad.net/~kicad-developers
>>>> More help :
>>>> https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list:
>>>> https://launchpad.net/~kicad-developers
>>>> Post to :
>>>> kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> Unsubscribe :
>>>> https://launchpad.net/~kicad-developers
>>>> More help :
>>>> https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list:
>>>> https://launchpad.net/~kicad-developers
>>>> Post to :
>>>> kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> Unsubscribe :
>>>> https://launchpad.net/~kicad-developers
>>>> More help :
>>>> https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list:
>>>> https://launchpad.net/~kicad-developers
>>>> Post to :
>>>> kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> Unsubscribe :
>>>> https://launchpad.net/~kicad-developers
>>>> More help :
>>>> https://help.launchpad.net/ListHelp
>>>
>>>
>>> _______________________________________________
>>> Mailing list:
>>> https://launchpad.net/~kicad-developers
>>> Post to :
>>> kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe :
>>> https://launchpad.net/~kicad-developers
>>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
References
-
UPDATE: Diode pins swapped in KiCad Libraries
From: Carl Poirier, 2015-04-24
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Bob Gustafson, 2015-04-24
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Carl Poirier, 2015-04-24
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Thiadmer Riemersma, 2015-04-24
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Carl Poirier, 2015-04-24
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Garth Corral, 2015-04-24
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Carl Poirier, 2015-04-24
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Garth Corral, 2015-04-24
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Carl Poirier, 2015-04-25
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Adam Wolf, 2015-04-25
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Carl Poirier, 2015-04-25
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Carl Poirier, 2015-04-25
-
Re: UPDATE: Diode pins swapped in KiCad Libraries
From: Samuel Dolt, 2015-04-25
