Полной обратной совместимости на данный момент нет и скорее всего не будет это связанно с ограничением ресурсов разработчиков …
Mod edit: see the next post for translation. The original context was problems when trying to migrate projects from v4 to v7.
That translates to:
There is no full backward compatibility at the moment and most likely it will not be due to limited developer resources…
But I believe that is false.
From what I understand and from my experience, KiCad have full backwards compatibility. But that doesn’t mean that you won’t experience problems.
As already described, newer versions are more strict than older.
If you’ve used symbols and footprints from KiCad libraries, updating these to symbols and footprints from current libraries will probably mean that you have to do some manual fixup.
As described in the links that I posted, there may be some manual steps that you have to follow.
Can we tone down the language used here.
While frustrations are unfortunate, it is not permit to dissuade people.
products evolve but how they evolve depends on the architecture that aspects are built upon and whether they can easily expand to accommodate capability.
As long as new capabilities are expected (eg teardrops, curved traces, constraint editors) then the expectation that the file format has to change, FACT and thus FORWARD compatibility will be a challenge
While migration and/or backwards compatibility should always be accommodated the question is how far back?
To v0.0.1 ? At some point the technical debt is too heigh causing future design issues and Dev burden and thus a line has to be drawn… v5 would appear to be a reasonable line.
This isn’t a failing of FOSS or Kicad it is a decision. Take Gitea as an example… at one point to UPGRADE from an old version you had to update though all the point releases (1.6 → 1.7 → 1.8 … 1.10) but then there was CLEAR migration replay that would take you from 1.10 → 1.21
To put this into perspect … MICROSOFT, that well known large software org, their newer OFFICE suites are not able to open olde doc files so much so that MS had to sort out a VM to run office2 in a win3.11 environment as the doc files wouldn’t open 20years later NOR would that office version run on newer windows …
Likewise MATLAB and their SIMULINK package is notorious in forward and backward compatibility in a period of 6months… alot of my time is spent is archiving a project and a specific version of MATLAB before migrating,checking and CORRECTING and right now Mathworks do not guarantee compatibility for the Simscape ports BETWEEN versions and one migration resulted in X10 simulation increase until they were all manually replaced with the SAME library part.
So before people start aggressively critisizing people’s work … think, likewise there are ALOT of people here, on IRC, on Discord, in Gitlab, on the ML that will help
What are you talking about ? If you saved a project in version 7, you cannot open it in 6… This is complete backward compatibility… This is not even a transition between 4 to 6… This is only 1 year of development MICROSOFT is a leader in backward compatibility in this regard, I can now run a program that is 15 or more years old and it will work
No, that is forward compatibility as Naib explained. KiCad has no forward compatibility, and has never had any plan on implementing it as far as I know.
If you save a file in v7, you cannot open it in v6. But if you save it in v6, you can open it in v7.
The problem is that going from v4 is a bit more troublesome than going from v5 or v6. This is because of huge changes between v4 and v5.
I think you mix up backward and forward compatibility. When a newer version of the program can open files created with a older program version, then you have backwards compatibility. That is the case in KiCad, where KiCad 7.0 can open files from KiCad 6.0, 5.0 and 4.0**, and it is also the case in Windows and many other programs, but not in every program.
When a older program version can open files created with a newer program version, it is forward compatibility. KiCad does not have forward compatibility. You can often not open files created in KiCad 7.0 with KiCad 6.0. This is sometimes also the case in Windows where programs compiled for Windows 11 may or may not run on Windows Vista (but there the gap is bigger, which is expected and easier to archive than in KiCad).
** As far as i understand @wil001 , and he may correct me if this is wrong, doesn’t really have a problem that he can’t open files from KiCad 4.0 in KiCad 7.0 or that they would have wrong data (except maybe some library symbols/footprints that have been updated). But his “problem” is that KiCad 7.0 DRC reports many design violations that weren’t reported in KiCad 4.0. Which is not a actual problem, since they can be ignored.
Regarding the definitions of the terms “forward compatibility” and “backward compatibility”, Wikipedia seems to have this opinion:
In particular applied to KiCad, “input” would be the project, schematic and board files etc. This means that “forward compatibility” is when v6 can open files created by v7 or even v7.99.
Correspondingly, wikipedia has this to say about backard compatibility:
In other words, applied to KiCad, if I create a project in v6 I can open it in v7 and v7.99 nightly if KiCad has backward compatibility.
I think this part of the Wiki page is more pertinent . . .
. . . but even that is very ambiguous and badly written in my opinion.
It’s not the data format that is “backward compatible”, it’s the new version of the application that is backward compatible with previous versions of the application’s data file format.
If I read and understand this correctly, it is the same practical case as the last sentence I wrote in my previous comment. A new version of the application (v7, v7.99 nightly) can open a project from a predecessor (v6).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
