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.
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?
-- Chris
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
