kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 10/04/2016 02:49, Chris Pavlina a écrit :
> Possible to implement, of course, but that could get rather messy as the parser
> has to be taught to ignore things it doesn't recognize, which is not exactly
> easy given the context-sensitive nature of our kinda-sorta-pseudo-parser
> implementation...
> 
> I don't see the problem with refusing. It ensures that even subtle changes
> (like when we changed the anchor point for multiline texts) don't cause
> trouble. It's forward, not backward - it's not like it'll ever prevent people
> from opening old boards in new versions, it just means they might have to
> upgrade to open new ones.

I Agree with Wayne:
For me, warn the user about possible problems is enough (AFAIK, Altium does that).

* If a new feature is added and not used ( this is a very frequent case ) the file is perfectly
readable by the older version. Therefore, refuse to load this file is a bit annoying.
(think to rounded rect pads for instance)

* If it is used, currently the loader does not load the file ( an error message is shown ), but the
used was warned.

In very rare cases, the file does not change, but creates a very small change in a board or a footprint.
The only one case I remember is a very small change in multiline texts vertical position.
This is certainly not a mess: this is very easy to fix, if this minor change created an issue.

Ask the user to update his kicad version just to read a board sent by an other user is not always
possible.
For instance daily build versions are not immediately available for all platforms.
(Stable versions are an other story).

> 
> On Sat, Apr 09, 2016 at 08:00:11PM -0400, Wayne Stambaugh wrote:
>> Chris,
>>
>> I looked at this patch and I thought you were going to add a check to
>> warn the user that the board file may not load.  Your patch will refuse
>> to load any previous versions even if the file does not contain any new
>> features.  I'm not sure flat out rejecting newer board versions is a
>> good idea.  I would rather warn the user that it might fail to load and
>> than fail if there is anything that the parser can't handle.  If there
>> are no new features in the file, then it should open as expected.
>>
>> Wayne
>>
>> On 4/9/2016 11:42 AM, Chris Pavlina wrote:
>>> Here's a patch that checks the PCB file format version against the currently
>>> supported one, and displays a message explaining the situation if the PCB file
>>> is too recent. I assumed YYYYMMDD format for the version. Message looks like
>>> this:
>>>
>>>     KiCad was unable to open this file, as it was created with a more recent
>>>     version than the one you are running. To open it, you'll need to upgrade
>>>     KiCad to a more recent version.
>>>
>>>     File: <filename>
>>>     Date of KiCad version required (or newer): <format version, reformatted as date in locale>
>>>
>>> A couple changes still have to be made - this is only for comment, not to
>>> commit.
>>>
>>> 1. Also check footprints - we'll have to add versioning to those, as it's not
>>>     there at all right now as JP said.
>>> 2. Use a more friendly error dialog without the "IO_ERROR" and source code
>>>     location, at least in non-debug builds. That will frighten people. :)
>>>
>>> On Thu, Apr 07, 2016 at 09:47:41AM -0400, Chris Pavlina wrote:
>>>> Hi all,
>>>>
>>>> I'm targeting this email primarily at Wayne as versioning and release policy is
>>>> involved.
>>>>
>>>> We've got a bit of a problem right now. We're currently adding features to the
>>>> pcbnew format - JP just merged rounded-rect pads and has a patch in development
>>>> for custom pads, and I'm looking at a patch to add angled fields. Problem is:
>>>>
>>>> 1. We're not bumping the file format version, so even though we're writing
>>>> files that contain features (actual COPPER features!) that old versions won't
>>>> understand, we're not marking them as such, so they'll either give nasty
>>>> file-corrupted errors, or fail to load silently.
>>>>
>>>> 2. Even if we did, pcbnew currently ignores the format version.
>>>>
>>>>
>>>> I propose the following:
>>>>
>>>> 1. Patch pcbnew to check the format version and give a friendly "your KiCad may
>>>> be out of date"-style warning if it's too high a number.
>>>>
>>>> 2. Accelerate this patch to a minor stable release to get it out there before
>>>> these new features make it into the next major release.
>>>>
>>>> 3. Adopt a policy of properly bumping the version number any time a feature is
>>>> added.
>>>>
>>>> Thoughts?


-- 
Jean-Pierre CHARRAS