kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 1/14/2015 2:13 PM, jp charras wrote:
> Le 14/01/2015 19:32, Miguel Angel Ajo Pelayo a écrit :
>> As a reference: In other EDA tools they can load newer files on older
>> versions of the software.  They just open a warning window with
>> everything which is not read/processed, and tell you everything not
>> readed will be lost at next save.
>>
> 
> There is not a lot of free EDA tools so I don't know the actual meaning
> of "In other EDA tools"
> 
> Keep in mind commercial software has very different constrains:
> 
> 1 - they have much more (I am expecting) man-hours we have.
> 2 - because they are very expensive, they *cannot* ask for user to
> update the software. Kicad is free and free of charges. We can ask.
> 3 - This issue is widely due to the fact we have a repos to which allows
> user to download, compile and use current development versions. How many
> commercial software have such a repos ?
> 
> To tell the true, I am not sure an old version opening and saving a file
> still gives a working file: you don't know what is lost ( and be sure
> the user is not able to know what is lost, and if this is an important
> info, and warn he is not usefull).
> 
> To minimize issues when a old Kicad version open files created by new
> versions, I am using this way:
> When a new feature/option exists, it can have default values.
> When this option uses default values, theses values are not saved, and
> therefore do not create issues.
> For new features, obviously if they are not used, avoid to save any info
> about theses features.
> This is not perfect ( mainly do not save defaults creates a major
> constraint: defaults cannot be modified ) but it helps.
> 
> Having said that, I am also thinking we just skip data not recognized by
> a old kicad version when reading a new file, warn the user and do not
> reject the entire file, but we ask the user to update the Kicad version.
> 

I just thought of another potential issue caused by ignoring unknown
tokens.  What if the tokens are actually invalid due to file corruption
or someone wrote a bad board generation script.  What do you do in that
case?  The file is invalid but you still parse it anyway and throw away
the invalid stuff.  I'm not sure that is necessarily a good thing.

Each new argument seems to support the original decision to not attempt
forward compatibility.  We have one argument in favor of forward
compatibility (user convenience) and a whole bunch of valid arguments
against forward compatibility.  To me, it seems like the effort and
risks don't justify the gain.