Elsewhere on this forum I have commented that I am using a nightly version which works well and has never crashed. But I am not a “power user” and others might disagree.
I wonder if other users might venture into the nightlies as I did and then find they need to work with something reliable (as I did). In my experience some of the nightly versions are much better than others. Some versions might crash “out of the gate” while others seem very useful if not perfect. Once you have developed nightly compatible libraries (or designs) you might not want to revert to the last stable release. Or you might find yourself hooked on some of the newer features.
Would it be reasonable to establish a place on this forum where users discuss (and maybe vote) for best (and for the sake of discussion, maybe also worst) recent nightly versions? If someone finds him/herself stuck this could provide a practical method for rescue, like a lifeboat…
Anyways, I might recommend starting the recommendations after the feature freeze/file format freeze. There’s so much going on now in the development that unless someone can do some systematic continuous testing between commits, recommendations aren’t very useful unless you happen to have exactly the same workflow and are in the same phase of a similar design.
Because the situation changes. It could be useful again soon. Feature freeze has been planned to be within a couple of weeks (for KiCon 2020 to be exact).
File format freeze and feature freeze are supposed to be the same thing. I guess there is some chance of some critical bug that requires a file format change after feature freeze, though.
Just wondering:
Is there a baked in backwards compatibility for future features in the file formats?
I understand that Current V5.99 file format is not readable for KiCad V5.1.
It would be nice if any changes made for KiCad V7 would just be additions, and KiCad V6 would be able to read KiCad V7 files, and then just omit all additional features not implemented in the older version.
Ideally the user is warned that the read of the “future” file format is not complete and some parts are missing. A very simple and flexible way of handling such things is to save all lines which could not be interpreted in a text window, with an option to save it.
I would much rather have a 95% conversion then a “Your’re out of luck, I won’t read this file” message. For now it would be difficult, as I understand Eeschema changed from what it was to S-Expressions. But those should be near ideal for this as any changes will be locally contained in the file format.
For me, the absence of this feature is the single reason I have not been test-driving KiCad V5.99.
KiCad’s development process is only to provide forwards compatible file formats, not backwards compatible. Doing what you propose would be quite difficult from a development point of view, and there is very little motivation for us to take on this extra work that would end up really slowing down development.
It will never be as simple as just “ignoring” things that are not understood: this will almost always result in a broken design, which at best will be extra work for the designer and at worst will be extra work for more people when the designer opens a “false” bug report about their design being broken.
Our recommendation has always been that people testing nightly development builds do so on a copy of their designs, so that if they need to revert to the current stable release they are able to do so.
To me they do not mean the same thing. Do you mean that one tends to drive the other? I can think of one 5.99 feature for example: In Eeschema highlighting what has been selected…which I would expect to not correspond to any change in file format.
There are hundreds of features that don’t touch the file format. What I meant was, the feature freeze date is also ideally the date that the file format stops potentially changing. We don’t keep track of a separate “file format freeze” schedule.
I would be fun if we have statistics on runtime for each version, and then we could publish it somewhere, then we could plot it and you would be able to decide if you wanted to bump locally
Given a user started to used the latest, it would start counting… but if the version is unusable the user would probably revert a bit. If multiple users do this it would be evident that this does not get a lot of runtime.
