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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
