Using property names in part creation

It is the things that you don’t know about that cause problems. I’m trying to populate (correctly) as much as practical, so that all of the designed functionality is available going forward. Like the <spice> tags. I understand what they are for. For specific components the information works well, but generic parts need to be able to provide instance specific values from external information. I see the syntax for providing substitutions, but everything seems to come from property values. If the user can not set them (like the part number), then it is very limited.

We really need access to those historical design notes. Having some of that high level intent would making understanding implementation a lot easier. Even if that implementation ended up branching away from the original design.

I’ve been using that python checking script as a lint check for my parts. It would be helpful to be able to turn off some of the warning messages. From the command line. I already know that I am working with through hole parts, so I do not need to be told how to switch to surface mount. Same for the svg already processed messages. With what I am doing, reuse is the expected case. More useful would be an orphan check, reporting any svg files that did not get referenced by any of the fzp files. Or delay reporting the already processed message until something in the svg requires reporting in the current context.

Knowing more about what the tags (are intended do) do could help in that cleanup process. Or point to other validations to add to the checking script.

The part set I am creating obsoletes 1 core part. The information I found is “How to contribute a fix” on page fritzing-parts/CONTRIBUTING.md at master · fritzing/fritzing-parts · GitHub. That seems to be incomplete, or changed. I did a bulk cleanup to adjust the family names in the obsolete parts cleanup obsolete family text prefixes by mMerlin · Pull Request #158 · fritzing/fritzing-parts · GitHub. To match the partial information I had found then. The latest information does not say anything about modifying the family name. I think it is necessary to change the family name, so that the obsolete part does not show up as available in the selectable options in Inspector. For the part that replaced it. Code could handle that instead.

referenceFile attribute is in the fzp files, not svg. It is not part of svg. There is no reference I can find for it in the svg attribute documentation.

I need to put creating a complete build environment for Fritzing back on my todo list. I successfully built 0.9.2b on a Ubuntu 12.04 VM a couple of years ago. After a lot of work to get all of the correct dependency versions together. Then priorities changed again.

We need to get a discoveries section started someplace. One if the wikis is an obvious choice. To record some of this information. As a substitute for the full documentation that does not yet exist. Or use as the WIP documentation. Initially could be some cut and paste from the forum threads. But gathered together, and potentially updated with the most recent/complete details.

The new version dumps that and has a ton of command line options (and more can be added easily now the mechanism is in place.)

Yes, I agree. AFAIK the current modifiable fields are handled by hard coding in the app. I would much rather see an api that would let the user be able to specify modifiable fields from the fzp file. However, someone has to write that code in the app, and at present we have a lot of bugs that need fixing and almost no one working on any of it, so that is fairly far down my list (but is on my list!). I did manage to get my top two bugs (invalid parts crashing Fritzing and corrupting the parts database and Parts Editor not registering its fzp and svg files with the main window, meaning you can’t reload a part even if you say “don’t save” on exit, fixed and in the 0.9.4 release, but that took me about 2 or 3 months or work for each to figure out the fixes, and even then it is only because the crash was a worse outcome, that it was reasonable to include them. I have no idea if they are entirely correct, they fix what I wanted done but may affect something else I’m not aware of.

@KjellM is the best chance of that. He is (I think anyway) in Berlin and in contact with the remains of the original developers. If such notes exist, he will have the best chance of finding them, but I suspect they may not exist.

Yep, the ones that are there are ones I have run into myself or when fixing other people’s parts. The ones that create Errors will break Fritzing in some manner, the rest are Warnings because they are unusual and may be wrong (but sometimes are intended.) They are nowhere near complete because I don’t know enough, and trying to restart development was the more important task. Luckily the Ansler folks stepped in and restarted development, because I was getting nowhere for a couple of years :slight_smile: .

That is likely to be a problem. There is a part obsoleting mechanism (it is referred to in the part file format document like this:

Obsolete parts use a special version syntax <version replacedby=""> The value of the replacedby attribute is the moduleId of the part which replaces the obsolete part. There are many examples of this in the pdb/obsolete folder. The replacedby attribute can also be applied to individual connectors; see the Connectors section below.

AFIK this is the only documentation on how to obsolete parts. There used to be a section in the CONTRIBUTING document (or perhaps somewhere else) but its entire content was “tbd” and as far as I know it has never been done/documented. I expect that the parts maintainer knew how it worked and did it when required, but I think he may no longer be with the project. So you probably need to figure out how to obsolete the current part with your new one. Figuring this out and documenting it is on my todo list because it will be needed to clean up core parts once the script is done. I of course am no where near that far ahead yet though. The mechanism is intended to replace obsoleted parts in old sketchs with the new one. The one time I tried that it screwed up, so I just reloaded the .fzz and said “no don’t update”, so I think it (or possibly some of the obsoleted parts) have problems.

This should (note the weasel word :slight_smile: ) be dealt with by either of both of the part being in the obsolete folder and/or the “Obsolete parts use a special version syntax `” in the pars file format document. One or the other of those should block it from showing in Inspector.

It is actually in both. In the svg it is in the desc field of the metadata (I don’t know whether that is an svg standard field or a Fritzing convention.) In an svg it looks like this:

<desc
  id="desc2">
    <referenceFile>PIC24FJ128GA204_8903ac93cd3db0fdd1143f9428ed518e_1_breadboard.svg</referenceFile>
</desc>

which the script checks for and corrects as necessary. Again I know of nothing that cares about it (because many of them are wrong with no known ill effects)

I expect @KjellM is the best one to decide on an appropriate place. I certainly have no objections, I don’t use the wiki because I don’t know anything about wikis (along with a lot of other things like github :slight_smile: )

Peter

I thought I had the latest version (as of a week ago) from the repository. Is the new one in a different place, or just not pushed to gethub yet?

So we also need some (an expanding set of) automated regression tests.

I’ve seen that, and have a few notes from when I did the bulk family cleanup on obsolete parts a couple of years ago. There were no complaints on the pull request, and it went in fairly quickly, so who ever was doing the work then was satisfied that it was correct. Or at least better than what was there at the time.

That should be as simple as moving the fzp and svg file into the obsolete folder structure, adding that mentioned replacedBy entry, and maybe changing the family name per my older notes. Already on my list, once I do a bit more testing of the new parts. They all seem to be minimally functional at this point. If I push it to my fork of the parts library on github, can you pull it down and do some cross checks? From comments, you are not really comfortable with git and github, but I can walk through the steps needed. It will also need the redirect of the parts library, and database rebuild I have been doing here, and talked about in another thread.

I’ll have to test that carefully. My last round was just to cleanup things already in obsolete, and I did not have any information then about the semi-automatic replaced of obsolete parts in existing projects.

Agreed, should. From a quick visual scan of
grep -Ei "property.*family" obsolete/*.fzp
everything currently in obsolete has the prefix matching what I did 2 years ago. It is not hard to do an initial test without that, to see what Inspector shows.

I do not remember seeing that. Can you provide a link to the document? But using, that, or even that replacedBy attribute COULD be used by the code to filter obsolete parts. Don’t know if at actually DOES.

Mixing terms a bit. In the fzp file, referenceFile is an attribute of the module element. In the example svg, referenceFile is an element, with a parent element of desc. Searching the online svg documentation does not show any reference to either a referenceFile element, or any element with a referenceFile attribute. The information for the desc element shows <desc> - SVG: Scalable Vector Graphics | MDN effectively free form text. Both svg and fzp files are xml based, which can be extended readily. Parsers are generally supposed to just ignore things they do not understand. So it is quite possible that Fritzing is using an extension that recognizes these. But best I can tell, it is not true svg.

There are other capabilities as well, but, just like posting here, it is mostly just text. Most things posted here could be pasted into a wiki page, and work just fine. Again like here, there is a toolbar available to help out with common things. Github wiki handles several different text entry formats (markup languages). It converts automatically. I can work with others, but tend to stick with markdown, because it is what is generally used for README files (README.md), and displays correctly in gh_pages. And I use it a lot in other places. Again, like here, there is preview available to see if you get what you expect. The wiki data entry screen acts like not much more than a simple text editor. Or very simple word processor. The page (document) title is something that can be referenced (linked to) from other wiki pages.

Not pushed to github yet (nor finished which is why.)

I don’t think there currently are any regression tests (but I could be wrong)

I should be able to clone and install your fork without problem. My usual problem with github is not being able to sync my fork on github to the parts master. The last time submitted a part, I ended up deleting my fork on github and re doing the fork then cloned the new fork locally. When I try the fetch or fetch all commands, my github fork gets out of sync with the master (or at least it appears that way). A clone of an existing repo and replacing the local version of the parts library shouldn’t be a problem.

The part file format doc on the wiki here:

it is just after the author, version etc xml. I remember another comment somewhere that I can’t find right now that said something like “there are lots of parts to use as examples in the obsolete folders”

Peter

I am coming to the conclusion that the best way forward here may be to go back to basics. By that I mean do a revision of the part file format document to make a specification document for parts (preferably one that is easy to automatically check.) and that is more complete than the present document. If possible, documenting all the properties that can be set and what they do (although that is likely to be time consuming.) From there, the check script needs to match the new document and once that is done, core parts needs to be converted to match the new document (which will be a lot of work.) I am somewhat concerned that there are no longer some of the dissenting voices from when the parts checking script was written a couple of years ago posting any longer. The discussion could occur here, on github in the fritzing-app issues or on the slack channel (although that is a much narrower audience and this probably wants to be as public as possible!) @KjellM is probably who should decide if this is a good idea, and if so, where the discussion should take place. At a minimum there should be a post here in the forums directing anyone interested to where the discussion is taking place, because we want as much input as possible assuming this goes ahead. As noted here:

What I consider to be a bug: an apparent hard coded svg in the code that substitutes for the schematic svg if editable pin labels is true exists. I had not run across this issue before, and it took me a while to figure out what was going on. The format of the hard coded svg is poor in my view as schematic pin lengths are .2 in long, rather than the .1 in long suggested in the template files and possibly the part format file document. Space in schematic is precious, in that if the pins are short more parts can fit in a given space and you can fit a larger schematic in (for instance) a 8.5 by 11in page. I would like to see that set as the standard for most parts. As well in my view it is desirable to set a common width for lines (probably the same as the size of a created wire so the connections match in size), but as noted in the past there were people that didn’t want the level of constraint. Thoughts?

Peter

More complete would be good. More structured / segmented too. Not a single document. A series that is linked together. We have the technology, let’s use it.

Being cautious of the intent. One way to read that, would be say create a new format to replace the old. Which would of course require breaking code changes. Which would likely break the application, (at least library access) for anyone unable to upgrade. Good idea, but add caution.

Some levels of hard-coding have their place. Here, I think, it should be more of a hard-coded default. I have seen some template files in the source code folders. I do not consider those to be really hard-coded, since they could potentially be modified without touching or rebuilding the code. Assuming they are used as a run time resource, not compiled into the code. Not following the published rules is a separate problem, hard-coded or not.

Screen space is always at a premium. The actually dimensions do not matter though, as long as things are consistent. Double the dimensions (of everything), halve the screen scaling, and you are back where you started. Individual parts that are different are a problem.

I like the schematic connection point lines thicker than the wires. Or some other presentation difference, to make the boundary between part and wires visually distinct. But that is just me.

Constraint for some things is good. Consistency is important. Which exact rule is less important. Artistic license gets tossed out, when it gets in the way of functionality. Which included being to tell at a glance what type of things are being worked on.

Not necessarily breaking code changes, there is capability to check the Frtizing version number in a part and apply previous behaviour to parts so as to not break older parts. We just have to keep that in mind with non compatible changes.

True, and that is what I would like to avoid. At present parts in core are different sizes, what I would like to see is as you say is consistent size / spacing rules for parts in core (for those not wanting rules, anything goes in user provided parts because there is no way to control it, but we have control of what gets added to core parts.)

Color is another option. A change to the graphic standards for pin names would I think be another way to do the same thing by making the color of a part pin a different color than that of the wires. I don’t know if that is true at present though, or if it would be enough.

Peter

But what would older code do with a part from the updated library that had the newer version number? It would not know how to handle it, and likely not work. From the user perspective, the library is now broken. You would have to maintain a complete copy of the older version of the parts library until everyone (which never happens) is using the newer code that understands the new version.

The version number by itself supports backward compatibility. But not forward compatibility. The only way I see to do it, without breaking things for existing (non-upgraded) users, is a separate ‘version 2’ library repository that the new code would look for on install. That would start as a clone of the existing library, but then have the changes proposed incorporated. Either in bulk, or over time.

EDIT: Or a version 2 branch in the same repository

Current part, Fritzing version 0.9.4 (current version) with Edit pin labels true set in the fzp file. Because of Fritzing version 0.9.4, the code acts as now, substitutes the boiler plate svg (which breaks header parts for instance.) as now and the part works. New part, Fritzing version 0.9.5 (not yet released) uses the new mechanism to find the position of the labels (which is I suspect why the overlaid svg) and does not break if applied to a header, and does not break older parts that do not recognize the new functionality because their Fritzing version is less the 0.9.5. If the version number is less than the Fritzing version the change is made in (likely not 0.9.5 :slight_smile: since this work hasn’t started yet), the current code is used, if the version number is later than that, the new code is used (a simple if statement and some additional code bulk because of the two code streams, but easily doable.) If the part is in core parts, the obsoleting mechanism will allow the new part and new functionality to work by swapping out the old part (or not as the user chooses, as it should be). The designers thought ahead when designing the code base and similar things are already there (the format of parts has changed over the years such as the nested copper layers in pcb, but old parts still work fine in old sketches.) We need to be careful to test old parts when making such changes but it should be possible to do if we are careful. No need for different repositories (which is a maintenance nightmare.) unless I am missing something.

Peter

That is not quite the scenario I was trying to describe. Let’s try a hypothetical example. That family of parts I am working on could be described to Fritzing in a much more condensed format. It is really only one part with selection of different image files based on the selection of the size, polarity, and footprint. Those 16 fzp files I created are identical except for:

  • module id attribute
  • referenceFile attribute
  • title
  • property values for ‘size’, ‘pcb pad’, ‘variant’
  • image attribute of layers element for each view

Those are the ONLY differences.

So, suppose I propose a change to allow that to all be described as a single part. One moduleId, referenceFile, title. With an adjusted element and attribute syntax to supply and select all the alternate information. Like this.

There are many other ways of implementing the same concept. This is not optimized in any way, just a quick description of what I can visualize, and should be an obvious extension of what is currently being used.

<properties>
  <property name="size" type="condition">
    <value sort="1">20mm (0.8in)</value>
    <value sort="2">32mm (1.2in)</value>
    <value sort="3">38mm (1.5in)</value>
    <value sort="4">60mm (2.4in)</value>
  </property>
  <property name="pad type" type="condition">
    <value sort="1">standard</value>
    <value sort="2">narrow</value>
  </property>
</properties>
<views>
  <breadboardView>
    <layers condition="size='20mm (0.8in)'" image="breadboard/20mm_example_breadboard.svg">
      <layer layerId="breadboard">
    </layers>
    <layers condition="size='32mm (1.2in)'" image="breadboard/32mm_example_breadboard.svg">
      <layer layerId="breadboard">
    </layers>
    <layers condition="size='38mm (1.5in)'" image="breadboard/36mm_example_breadboard.svg">
      <layer layerId="breadboard">
    </layers>
    <layers condition="size='60mm (2.4in)'" image="breadboard/38mm_example_breadboard.svg">
      <layer layerId="breadboard">
    </layers>
  </breadboardView>
  <pcbView>
    <layers condition="size='20mm (0.8in)' and 'pad type'=narrow" image="pcb/20mm_example_narrow_pad_pcb.svg">
      <layer layerId="copper0"/>
      <layer layerId="silkscreen"/>
      <layer layerId="copper1"/>
    </layers>
    …
  </pcbView>
</views>

Since it jumped out at me as I was writing the above, here is an extension/variation I like better, taken from the substitution done for spice entries. It reduces the duplication even more, by getting rid of the separate conditional layers element entries for each view. Closer to the current usage.

<generatedValues>
  <value name="size_in_image" condition="size='20mm (0.8in)'">20mm</value>
  <value name="size_in_image" condition="size='32mm (1.2in)'">32mm</value>
  …
  <value name="footprint_in_image" condition="'pad type'=narrow">_narrow_pad</value>
  <value name="footprint_in_image" condition="'pad type'=standard"></value>
</generatedValues>
<pcbView>
  <layers image="pcb/{gen size_in_image}_example_description{gen footprint_in_image}_pcb.svg">
    <layer layerId="copper0"/>
    <layer layerId="silkscreen"/>
    <layer layerId="copper1"/>
  </layers>
</pcbView>

The newer code would see that as equivalent to 8 parts in the older format. 16 parts, if I had added in the polarity variation that only affects the schematic view, but the point is, what would Fritzing 0.9.4b or earlier do if it saw that in a library part? Regardless of the version number in the part? When the user tried to drag it from the parts library to a view.

This particular case could be handled by the library update process. It could automatically generate the 8 or 16 parts, and store them in the parts library in the older format, instead of this condensed version that is easier to maintain. Easier because there is only a single copy of all of the rest of the part information that is the same, and should STAY the same, if a detail changes. Like adding another tag. Or spice information. Which would also need to support some form of the conditional syntax.

Very likely screw up. It is too large a change from the current implementation (which assumes a single part to a single moduleId by and large, with variants having a different moduleId.) I’m not being that ambitious :slight_smile: , only considering things I think can be fitted in to the current constraints. The idea of an external script or program that converts this format to the multiple standard parts is probably the way to go here as that won’t break backwards compatibility. This does however bring up a good point, I hadn’t considered, a part that depends on new functionality won’t work in an older version of Fritzing which may be a problem. One way around that is to advise the user to upgrade to a newer version, but I don’t know if that is acceptable or not. If I am lucky, there might be a test for version of part higher than current version of Fritzing, that triggers a warning the part may not work, but I don’t think so.

Peter

Any documentation around on the variations for the current and older code? This comes from what should I put in the fritzingVersion attribute for the set of parts I am working on, to make them most widely usable? I was going to put 0.9.4b, since that is what I am using, but there is nothing special, that I know of, that should prevent them from being used with older versions of Fritzing. I saw reference to the change of color for silkscreen. Will the wrong color break older versions of Fritzing? With minimal work, I can test against 0.9.2b, and I think 0.9.3b using an appimage. But that is not very fine grained. I believe there were multiple smaller releases that all used those prefixes. The part intended to be obsoleted is marked with version 0.2.2.b.03.04.2550.

As usual no documentation that I am aware of. I usually use 0.9.4 as the Fritzing version because that is what it was made on. AFAIK there is only special code for some older versions of Fritzing where functionality has changed in the latest version and there haven’t been any such changes that I know of in the last two versions so your part should work in older versions. I don’t think there are a lot of older versions around any more. Some of the Linus folks are on 0.9.2 because that is what is in the app stores. The main change there is no parts editor I think (and possibly not copper1 within copper0 as well) which were added in 0.9.3b.

Peter

Exactly. But your earlier post about a new specification document would have allowed it.

For that particular case. I actually have some python code that comes close to doing just that. Because I have a different family I would like to do similar extension to that would be something like 144 fzp files. But other changes that fit in the part file format revision might not be so easy to work around.

That idea for a revised part format document needs some additional constraints to prevent this situation.

I doubt it. Not all users have the right knowledge to upgrade to a version that is not provided by the standard software management programs.

Or in the case of Fedora linux, what the package manager has. Unless you meant app store in a more general sense.

That possibility, or worse, silently failing, is why I want to know what fritzingVersion to put in the parts. My understanding from your usage descriptions says I want to put the lowest possible version that makes sense. In other words, the fritzingVersion value should be first/lowest fritzing version that the part is compatible with. Lower run time versions beware. The specified version or newer can safely process.

Again with lack of documentation, I’ll need to do some testing, to see what Fritzing does when that version number is higher than the currently running program. I can clone one of my parts to force a 0.9.9 version into the library, and try to run with 0.9.4b, or run 0.9.2b code against the library with 0.9.4b version parts.

@KjellM Do you have a suggestion where to dump some initial discovery information that will be collected doing that? Or better, reference to documentation that says what it should do.

Or maybe I can short cut the testing, with good confidence.

% grep -ri "fritzingVersion" * on the fritzing-app repository only found references in a few files. Ignoring the resource files, which are just data, most did not work with value variations. The exceptions are:

tools/scripts/resetversion.py does a bulk replace to change version numbers from 0.8.6 to 0.8.5 (probably for the schematic template change seen below).
src/autoroute/panelizer.cpp handles GroundPlane::fillTypeGround only for versions before 0.7.0
src/sketch/pcbsketchwidget.cpp only shifts pcb vias and holes after 0.7.2.b
‘src/model/modelbase.cpp’ has alternate processing for several cases. Quoting the comments:

// with version 0.4.3 ratsnests in fz files are obsolete
// with version 0.6.5 traces are copied to all views
// with version 0.7.6 mystery part spacing implementation changes
// with version 0.8.0 flipSMD is horizontal
// with version 0.8.6 we get a new schematic template
// with version 0.9.3 we don't have to worry about reversed wires

None of which seems to overlap with my parts. I can safely set the version the same as the single part I want to obsolete. 0.2.2.b.03.04.2550

And that points to another small :slightly_smiling_face: project. The part check (or other validation code) should check the fzp and svg content against the rules for the specified version. Even better, parse against all rule sets, to figure out what the (minimum) version should be. Bonus if it can report the part content and rule that results in not being compatible with an older version.

From that search, no check or warning. It just silently does alternate processing for a few cases. Which could of course result in real error messages, or unexpected output, if the content contains features that do no match the specified version.

I did not see anything related to that in search results.

A new spec isn’t in the cards, my intention was to specify some of the things that aren’t clearly stated in the part file format such as stroke-width on lines in the svgs, length of connector pins, using the minimum space possible for parts to provide more room (and consistency between parts in core) to constrain already working function to a smaller more consistent subset, not add new function. My intent is to get agreement on a desired or at least acceptable outcome and then work on fixing the current core parts to match, which in itself going to be a lot of work. Some parts in core parts are just plain broken right now. Some are odd sizes, that is more than enough work for some time to come. Many of the changes I intend are already in places like the template files (which are also wrong in that they are 72dpi with px as dimensions currently and scale incorrectly in Fritizing if used as a template in modern Inkscape versions.

I think silently failing is unlikely, unless the part is
invalid. I think (but don’t know for sure) there are
relatively few special cases. I believe separate copper0 and copper1 (as was the original standard) is about the only one I’m sure of. I’ve made lots of parts and other than obvious invalid xml errors never had one fail by tripping over a special case in the code. There are a bunch of special cases around making breadboards, but they are specific to how a breadboard needs to operate (always on the bottom for instance.)

You should be able to just create a part as an fzpz file, and change the version and load it. No need to put it in core parts. The only difference with an fzpz file is that is is in the mine parts bin, not core otherwise it is processed the same.

Someone lately referred to the package manager (possibly in Fedora, perhaps one of the others) as the “app store” and I reused the term probably incorrectly.

It may be that the original code was just left in as copper1 not a group of copper0 still works fine and is useful for things like edge connectors that need different pads on top and bottom of the pcb which the copper0 inside copper1 can’t do.

Peter

Hi there,

I agree that we need a good reference documentation for the parts format.
I even see this documentation as a precondition, before we can even think
about improving the parts format.

This documentation should be made available

  • on the website fritzing.org
  • from within the desktop application
  • as a printable cheat sheet (single page pdf with two or three columns)

Maybe the printable cheat sheet would be a good start?

Confirmed that it IS necessary to change the family property in the obsoleted part. If it is not changed, inspector offers it as a selection in the drop downs for other parts in the same family. Or more accurately, includes the property value from the obsoleted part in the drop downs for any matching property name, which when selected switches to the obsoleted part.

So should, but does not. In version 0.9.4b, commit c595162a1d06

Technically, it is not necessary to use that prefix I bulk sanitized previously. All that is needed, is to have the family of the obsolete part different from the family of any part that is not obsolete.

There was a sequencing problem in the old part, so I needed to add a replacedBy attribute to most of the connections as well. Doing the replace go the schematic view right. There were bogus wires added for (it looks like) all of the connectors with the replacedBy attribute. The way the showed up, it was easy to bulk select and delete those. Then a move (jiggle: move off and back) of the part on the breadboard got it to reconnect to the proper wires. That ended up deleting a bunch of traces on the pcb view though. Moving the part found bogus doubled pads under most of the connections. NOT the first couple of pins, which had a full replace. The names changed from “pin1” to “pin 1” and “pin2” to “pin 2”. Pin 3, 4, 5 were correct, and did not need replacing, but they did get the bogus pads. Starting at pin 6, all of the connector were being replaced by the same name, because the connector number was wrong (one off). Replacing “pin 6” with “pin 6” looks like a good opportunity for something to break. Doing the substitutions using the id instead of name got the the same (or at least very similar) result. Again though the replacements were overlaping. Change connector8 to connector7, change connector9 to connector8, etc. I also tried modifying the new part, changing the connector ids so that they do not overlap with ids in the obsoleted part. FritzingCheckPart complained about that, though I think it is technically valid (I changed the “connector” prefix on all of the connector ids to “cnnector”). Did not help though. Results looked a little different but basically the same problems. Just a couple of different traces on the pcb were messed up.

So either I am missing something for properly making a part obsolete, or there is a problem with replacedBy for connectors. I expect it is the same code, but to be complete, I said “no” on the initial replace requestor, then did the update from the part menu. Same results.

For collaboration, the wiki for either fritzing-app or fritzing-parts would be convenient … for anyone with a github account at least.

At some point, this documentation is as important as the implementation of the app. If enough parts just follow it, we will have to adapt the code. Of course it would have to be in document management (meaning, git). But with wiki, do you mean public write access, bypassing code reviews?
I’d like to automate syncing the documentation to the app and the website. With a public write access, this would require permanent monitoring…

@KjellM The wiki was an idea for collaboration, collecting, merging, referencing sources for related information. If needed, snapshots could be copy/pasted to more stable locations. That said, the wiki is itself a git repository, so it is under version control too. It is possible to git clone the wiki, just like the main repository, and push changes back. To really mess it up requires a lot more than just write access. An owner could force push completely new content, throwing out all of the history. Standard git commands work normally on the cloned wiki repository, so commits, when/who did, what changes are easy to check.