kicad-developers team mailing list archive

[Kaspar Emanuel <kaspar.emanuel@xxxxxxxxx>]

My 2c: let the parser ignore unknown/incompatible s-expressions and warn
the user when they are encountered.

On 14 January 2015 at 22:24, Martijn Kuipers <martijn.kuipers@xxxxxxxxx>
wrote:

>
> On 14 Jan 2015, at 21:07, Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>
> wrote:
>
>
>
> On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski <
> tomasz.wlostowski@xxxxxxx> wrote:
>
>> On 13.01.2015 20:11, Wayne Stambaugh wrote:
>> > This is a tricky issue that has been discussed before.  The general
>> > consensus in the past has been not to support forward compatibility.  It
>> > increases maintenance and complexity of the file parser for a minimal
>> > net gain to the user.  My preference is to force users that want to
>> > bleed on the edge to use nightly builds rather than try to maintain any
>> > forward file compatibility.
>>
> [snip]
>
>> OK, how about this:
>> - No extra version tokens (fits point A)
>> - Warning instead of error on unrecognized tokens (point C - no big
>> changes needed in the parser)
>> - If the opened file is produced by a newer version of Kicad, issue a
>> big warning when the user attempts to save it, that certain features
>> will be lost (points B and D - if somebody complains we can always tell
>> him he was warned). AFAIK this is what most commercial software does.
>>
>> Cheers,
>> Tom
>>
>
> Except for Acrobat Reader, all the other software I use simply tells me it
> cannot load the new file. In a corporate environment and especially on
> large projects no one wants to take the risk that someone obliterated some
> data. Let's say Person A sends Person B a file with data missing - what
> can Person B possibly do with that now? Person B was never aware of the
> warning that Person A ignored and the software is not psychic so it cannot
> say "hey, the last time you worked on this file it was Version X.Z, not
> X.Y".
> The problem gets worse and more difficult to detect as the project gets
> more complex. People need to understand the limitations of their tools and
> work with that.  As I said before people can negotiate what version they
> need and if necessary build/install to support a specific project.
> Otherwise
> why use file versions at all if we're essentially only using it to tell if
> there
> are newer features and essentially ignore it and write corrupted data
> anyway?
>
>
>
> I would be very happy with backward compatibility, especially if it would
> allow us to safe the file in the older format.
> This way, not everybody in the team needs to have the same version to be
> able to work.
>
> Of course, if someone saves it in the new format, then I would not expect
> an older kicad to be able to read it.
> Wayne could even decide that every format-change implies a version number
> increment, so we can tell the user to install kicad newer than version x.y
>
> I also think, this is not something that will happen every day, so we
> should not overdesign this. Forward compatibility for a EDA tool is not
> something I would advice, as there are just to many things that can go
> wrong.
>
> If it makes things simples, an external file-format converter would also
> be fine.
>
> Just my 2 cents,
> Martijn
>
>
> - Cirilo
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>