kicad-developers team mailing list archive

[Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>]

pe 22. helmik. 2019 klo 5.17 Seth Hillbrand (seth@xxxxxxxxxxxxx) kirjoitti:

>
> Once v6 is started, I'd like to freeze the v5 parsers and make a copy of
> the parsers for v6.  This would mean that all new format features would
> be implemented in a separate parser while any changes to underlying
> structures would require updates in three parsers (legacy, v5 and v6).
> This will be an "of course" for eeschema because we are re-working the
> format to s-expr but I think that it also makes sense to hold a fixed
> copy of the v5 parser with all its warts.
>
> Some requirements to do this:
> - unit tests that open v5 files and save to a known good v6 files
> - unit tests that load v5 files and compare expected data structures
>
> Nice to haves (but not required):
> - Save-as function that allows downgrades with limited feature sets
>
> Do people have concerns with this idea?
>

As response to what Seth said and also in general. I can of course say
nothing about how things should be done, but I can give my viewpoint as a
user and tester who has used nightly builds.

I use KiCad at work and therefore must have a safe way to continue projects
even if the development version of KiCad stops working. I can afford even
some crashes every now and then, but need some guarantee that I can go back
to a stable version. In ideal situation I could leave unused those features
which cause incompatibility with v5 and open projects with v5 if needed. At
some point it will not be possible, but I suggest that such possibility
would be kept alive as long as possible. Maybe it would give some potential
testers safety so that they would be willing to continue testing a bit
longer even if they had to switch back to v5 later. So, Seth's "nice to
have" downgrading or something similar would be great.

I don't know how different features have been implemented in the file
format, but is it possible to leave things unwritten in the file and handle
e.g. nonexistent property as default value? Like, if there's hatched zone,
it may have property hatching=true or hatching=false where nonexistent
key/value = false. False would not be written to the file. That way a new
property would automatically be compatible with v5. I think rounded
rectangles worked like that, right?

At the minimum I would appreciate if clear notice is given when a new file
format change is introduced and how it affects compatibility. Here in this
list or even in the forum in a dedicated thread. This will undoubtedly be
of interest to some (although limited amount of) people and will be raised
up in the forum many times in the future. I don't have long enough history
with KiCad to know how these things have been handled before.

Eeli Kaikkonen