kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

So - would you be happy with me just changing that to a warning that can be
clicked through instead of an error, and rewriting the message a bit to agree?

On Sun, Apr 10, 2016 at 03:17:17PM +0200, jp charras wrote:
> 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
> 
> _______________________________________________
> 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