← Back to team overview

kicad-developers team mailing list archive

Re: file version compatibility (optional tokens in s-expression files)

 

On 15.01.2015 23:40, Miguel Ángel Ajo wrote:
> I was talking about Altium in my previous email, and I believe
> the points you made are quite reasonable (in favor and against).
Hi Miguel,

Fully agree here.
> 
> I also didn’t know about the measures of not saving the unchanged
> defaults, which are quite neat.
Me neither. Did anybody propose to *not* save settings that are
considered default by the current version? What if these defaults need
to be changed (for whatever reason)?

> What about a flag in the loader parameters, disabled by default, but which could be
> used via scripting for extreme situations (recovery of broken files?). Dumping
> warnings to stdout should be ok.
Fine for me.

Cheers,
Tom

> 
> 
> Miguel Ángel Ajo
> 
> 
> On Thursday, 15 de January de 2015 at 21:37, Kaspar Emanuel wrote:
> 
>> 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 (mailto:martijn.kuipers@xxxxxxxxx)> wrote:
>>>  
>>>> On 14 Jan 2015, at 21:07, Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx (mailto: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 (mailto: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 (mailto: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 (mailto: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
> 



References