We’ve recently merged some changes that overhaul how netlisting works in order to expand how buses work and add some other new features.
There have already been some problems noted and I expect others to come in.
If you rely on KiCad, I suggest you may want to stick with 5.1 instead of nightlies until the feature merge part of 6.0 development is done, as there is a much higher chance of breaking changes / crashes right now.
If you like living on the bleeding edge, please try out your designs (especially if they use complex hierarchy and/or buses) and report bugs if you notice them (for example, netlist to PcbNew not being what you expect, etc).
Sorry about my ignorance, but what does “netlisting” in this context mean? Does it affect normal “Tools->Update PCB From Schematic” workflow if buses aren’t used? For me “netlist” would refer to the external netlist file.
Good question @eelik! In this case, I mean the translation of the schematic to the PCB in general, so this impacts both the internal netlist flow (“Update PCB from Schematic”) and the export/import flow (they are both doing much the same thing internally)
These changes affect all designs (whether or not buses are used), but the logic to handle buses and hierarchical designs is the most complicated and so there is the most chance for bugs to show up here.
Could any guidance on how to achieve this be made into an FAQ subject? I would be keen to try out recent nightly builds but am aware that at the start of the new development cycle they may not be stable so need a reliable fallback. Suitable warnings on potential data loss using nightly builds should be prominently displayed. Are the preferences seperate? Are files generated from nightly builds backward or only forward compatible?
In short, if the environment variable KICAD_CONFIG_HOME is defined when KiCad is started so that KiCad finds it in the environment, it defines the location of the configuration. Everything else can be defined in the configuration.
That’s also a very good question. I tried to ask in the developers list if we could get warnings when backward incompatible changes are introduced, but got no response. This far the new features have been incompatible only if you use them, at least chamfered pads and hatched zone fill. It’s natural that if you use a new board feature which affects shapes it won’t be compatible with older versions.
We will definitely publish loud and clear warnings when any compatibility issues come up with regular releases. With nightly builds, it’s harder to ask that any compatibility issues be warned about up front, because it’s possible for a feature that changes the file format to be developed, and then changed during the development process (causing multiple incompatibilities).
In general, like you say, files will only become incompatible once you start using new features.
The best workaround for this (in my opinion) is to make sure to keep your designs backed up (or even better, under revision control using Git or another similar tool) so that if you open a design in a nightly build and it is updated in a way that makes it incompatible with earlier versions, you can easily revert your design back.
If this sounds like too much of a hassle, I highly recommend waiting until later in the 6.0 development process to start using nightlies. Once we reach feature completion (or at least are closer to it), the changes will be better-behaved, better-documented, and generally less likely to cause you inconveniences.
V5.1 already can not read some pcb files that are produced by nightly as nightly includes a new pad shape (chamfered pads)
As @craftyjon already mentioned: This of course is only a problem if you have at least one such pad in the project.
What do you mean? Generally the nightlies can detect the objects, the problem is that older versions (say, 5.1) cannot detect them. We can’t easily add code to the older versions to detect the newer features.
Nightlies are not there for being used for production. They are there to give users an easy way to test new software as part of the development process. Nightly users are therefore part of the development team (The bug hunters)
I assume from a pure technical standpoint it might be possible to add support for generating files that are guaranteed to work with a previous version. (Or at least detect stuff that is guaranteed to break them.)
This will however take development time away from implementing new features. (And as it is an open source project you would really need to get buy in from the devs themselves that they should invest into making temporary backport features instead of shiny new ones.)