Revert Project to Older Version from the Nightlys

V5 is more of a V4++, similar structure with a few new features, so fairly easy to strip out the extras
V6 is a far bigger change in file structure

1 Like

More specifically and to avoid confusion: the schematic and symbol file formats have been completely changed in 5.99. The layout and footprint files have only added features compared to v5.

What about the “Generate Netlist”? Is that still there in 5.99?

Yes, of course. External netlist is needed for external tools. In-KiCad communication is done with internal netlist mechanism without the file, as it already was in v5. Netlist generation has been removed from other UI places than File menu.

So can V5.1 open a V5.99 generated netlist? It sounds like it should be able to

Wouldn’t it be great to be able to save in the old format? This is a frequent user error - I came here to search solution for this also. And it will only be worse with a release 6, people will not jump to new version overnight and this will fracture the community and reduce interoperability. The code handling old projects, schematics, and symbols is still there, why not add “Save As…” old format?

The symbol library structure is also new, so simply saving as a V5.1 schematic is not easy.

I agree that this is going to be a nightmare for careless users. A few extra “do you really want to do this” warnings may be needed

That has been discussed. I agree it would be good. However, there are a couple of reasons why it won’t be done:

  1. The developers want to spend their time with other, more productive features.
  2. The backwards conversion is lossy.
  3. Coding the conversion for the schematic would be a huge amount of work.
  4. When 6.0 is released there’s less need for backconversion because 6.0 is (more or less) stable and expected to be used instead of 5.

Note and remember that

the original v5 schematic file isn’t deleted, it’s kept there!!!


The problem of loosing data by careless opening and saving is true for the layout.

The layout part is relatively easy to convert. When the file format is frozen it should be pretty easy to write a converter as a python script. It would require mostly regular expression syntax to remove the parts not supported in v5. The schematic conversion is difficult, requiring “real” coding and intimate knowledge of two file formats.

The problem with all warnings is that people don’t read them.

You could make a wish to the issue database for clear and prominent warnings. I’ll give a thumb up.

1 Like

I know it won’t help you now but it is a really good idea to use git for your projects. It can help you a lot if you learn how to use it but even without knowing it you can keep a history of your work with these simple steps:

  1. install git
  2. go to your project directory a do git init - this will create a .git direcotry in your project and git will keep all its data in there
  3. git add * will add all the files to be monitored by git
  4. git commit -a -m “commit message” will “snapshot” all the files and store them in a commit (internally it stores only changed files)
  5. do steps 3+4 as often as you want, ideally with a descriptive message
  6. if you mess up, you can extract any of the commits into a separate directory

git can do much more for you, there are great GUI (tortoisegit for windows) for it, etc. but this is as simple as it gets and it is really an invaluable tool…

Only a few days ago

1 Like

That is a really nice improvement… I know that there has been a lot of work done on improving file formats so that they play nicer with git and other version control systems…
But I hear all the time that git is too complex and complicated and hard to learn and it is made for programming and … so I am trying to convince people that it can be really easy for basic history keeping and it can save a lot of headaches…

Using git with KiCad has been discussed here many times. I use it and many others use it. As a VCS it’s unnecessarily complicated for KiCad (or any other CAD) because most of the modern VCS features can’t be used with 2D or 3D data. Any simple centralized VCS would do. But git is good to know anyways.

I actually think Git is probably the least complicated VCS to use these days, because it has so much usage that there are many, many resources to make it easier. Lots of free hosting options (including private ones these days), lots of GUI tools if you don’t like the command line, lots of step-by-step tutorials because every beginner getting into software development must learn Git these days. Hardware developers can ride this wave too.

Sure you might say a different VCS has a “simpler” workflow, but in terms of the ecosystem of tools, tutorials, and hosting, nothing comes close.

I did not want to start discussion about pros and cons of git and other VCS systems… All I am trying to say is that if you are using no VCS - which is probably the case of the OP - it is really easy to use git only for keeping history of your work…

That is not true. They can be used but it may not be optimal… And it all depends of the format of the data. And even when treating the files as binary, there is still a lot of features that can be used: changelog, multiple remote repositories, branches, submodules (very useful for keeping your library of “vetoed” components), automation, … The only downside is that it is not able to merge files automagically and you need to do merging manually. But there are tools like git-diff that helps…

Agreed totally. I think many people get hung up on the idea that VCS doesn’t work on binary data (it does!) or that being able to diff and merge your board/schematic in a text editor is super important (it’s usually not, especially when only one person is working on the design).

Here is my opinion, and it hasn’t changed:

You are talking about using VCS in a multiuser environment… that is completely different than what am I talking about… git can be very helpful even for a solo designer. Or uf you have multiple people working on different aspects of the project. I am working with 3 other people and we use git as central repository. It works fine because we do different things that do not conflict much but we can all benefit from central versioned repository.

OK, I started with conversion of .kicad_sym files - I was so dumb to create a new symbol for 44-pin device in Kicad 5.99 :slight_smile: I can read kicad_sym files OK and very close (3-4 hours) to generating old style .lib/.dcm pair from them. It is small-ish Python script, around 300 lines so far. We’ll see how it goes. New format is a bit illogical in some places, redundant in others, but definitely better than the old one. I think JSON would be a better representation for object structure than S-expressions, but I realize the decision was made long ago.

My first attempt, backports kicad_sym files into .lib/.dcm and extracts lib from kicad_sch.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.