kicad-developers team mailing list archive

[Martijn Kuipers <martijn.kuipers@xxxxxxxxx>]

> 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 <mailto: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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail