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
