Please see: https://easyeda.com/forum/topic/The_best_way_to_design_a_PCB_in_EasyEDA-ThR3pwqIC and: https://easyeda.com/forum/topic/How_to_assign_or_change_the_PCB_footprint_assigned_to_a_schematic_symb_-1SoiAuM4Y To avoid having to completely redesign the PCB for the two different sets of footprints, do the PCB design first with one set of packages then clone the whole project, rename it then go into the schematic and reassign the footprints in the cloned schematic then do update PCB. You will of course have some rerouting to do but not from scratch.

The point of prototyping is to find bugs in the circuit and, eventually, add/remove some components. Cloning the project is an obvious dirty workaround. However, if one clone the project, then there are two independent schemes, two independent PCBs. This means that if one wants to add a new component (e.g. a fuse or a dip switch) it must be done in both schemas. Hence, dependence on a single schema is desired. Why single the schema? Because if a new component is added inside the schema, it will appear in both the PCBs. Maybe my question was not clear enough, let me be more explicit; In EasyEDA, is it possible to have one schema and two PCBs based on this single schema, while each PCB having a different footprint for some components (say few resistors and few capacitors)?

"In EasyEDA, is it possible to have one schema and two PCBs based on this single schema, while each PCB having a different footprint for some components (say few resistors and few capacitors)?" Not easily. In EasyEDA, the schematic is the master document for a design. It is the file that holds all the component info (which includes footprints and BoM info). When you create a schematic in EasyEDA it must have all the PCB footprint info in it before you can pass the schematic into PCB. When you pass the schematic into PCB, all the connectivity and package info is passed from the schematic into the initial ratlined (unrouted) PCB. If you want to change a footprint you change the package assignment in the schematic and then forward annotate that into the PCB (via `Update PCB...` in the Schematic editor and `Import Changes...` in the PCB editor). There is no way to back annotate a footprint change in a PCB back into the schematic. You can create a schematic with all the prototype components in it, create the PCB and then - after debugging the PCB - you can delete the footprints for the prototype parts and replace them from the SHIFT+F parts search. However this will delete all the component and connectivity info so you will have to manually reconnect them and hope that you have not made any mistakes because the Design Manager no longer knows about these replaced parts. The only way to keep the Design Manager up to date is by making the changes to the schematic and forward annotating them into the PCB. Therefore at some point, you must have two different schematics (which may be one that evolves into the other or may be two separate schematics). One with the components (which includes footprints and BoM info) you are putting onto the prototype PCB then either in parallel with or after building the prototype and doing all the debugging, a schematic with the final PCB components (which includes any changes to footprints and BoM info). I have to say that I have never come across the procedure you describe for building a debugging a prototype PCB with one set of parts and then building a production PCB using different parts and therefore a different PCB layout. For anything other than very simple low speed/frequency/component density PCBs, that approach is very risky. Anything that has high speed or fast edged/high frequency components and/or high component densities will be far too sensitive to layout constraints for EMC and Signal Integrity for a prototype layout to be any use in debugging a production design. A good example of this is in switch mode supplies. The difference in the lead lengths and spacing, as well as things like the ESR of capacitors and SRF of inductors, between leaded and SMD components can make such a difference in say the current sense circuit of a Current Mode SMPS or in the output voltage ripple of a Voltage Mode SMPS that a working prototype built with leaded parts may be hopelessly unstable when built on a PCB modified to take SMD parts. This is partly because the layout is different and partly because the parts themselves are different. Even apparently low speed circuits can fall foul of this type of problem. For example most leaded logic devices are very slow edged compared to devices that are available in more modern and exotic SMD packages, simply because the older slow logic families may not be available in the snazzier packages. So even though the circuit may be clocked at some "safe" low frequency, the edge speeds of the more modern logic family used on the production PCB may be orders of magnitude faster than on the prototype so all sorts of crosstalk and supply decoupling problems can occur that were absent in the prototype PCB. If you debug a PCB then change it and the parts on it and put it into production without going through the same rigorous debugging procedure (in which case why waste time and money with the prototype PCB in the first place?) then you are exposing yourself to a big risk. In effect you end up letting your customers do the product debugging for you. Not a good business strategy. :)

Despite your arguments are mostly valid, there are many cases when you need the above-mentioned feature. For example: I am developing the same HW with multiple sizes, hence each having a different PCB yet some components have a different footprint but the schema is the same. What if you have dozens of versions of the same circuit? Then you must have dozens of clones of the same project. If you decide to add a push button, you have to add dozens pushbuttons in all schema. Very difficult to maintain. Btw, this is nicely handled in gEDA. Why there is an option of changing the Package in PCB editor that does not work? Last question: Is there a built-in version control system (e.g. see CAD tool onShape)? That would be very useful for the development. Constantly renaming projects or adding prefixes to the components is a quite messy approach for a larger project. That would solve the issue with development, just create prototyping branch of the project and then merge it to the main branch of the project.

I agree: handling several slightly different versions of the same basic circuit is a tricky problem (though somewhat different from the prototype/final PCB issues I was discussing). I will look into the question of version control and post back.