harsh handling of format version bumps

The first part of this suggestion is introduced with commit d2ae471045ac81b6e97d5b441860081bc95eb2e7 by DJ Delorie on Mon, 2 May 2011

One problem with (4) is that if pcb is choking on a file, it can't know how or why it is --- naturally, the format changes will have occurred after its release date.

In a couple versions we will change the format to allow unit suffixes. Current git HEAD can handle this already, but 20100929 cannot. (In fact, 20100929 has broken support for nm/um units and there is a potential for Bad Things to happen rather than a simple parse error.) Plus, the measures-versus-numbers mess we had when introducing this unit support shows how inflexible the parser can be. These are the kind of problems we have now.

I agree that a warning should pop up rather than the frightening "blank pcb with no warning" we have now, but I think that's all we can do at this point.

In the distant future we hope to have an extensible file format -- then we can be much smarter about recognizing unknown fields, estimating the severity of incompatibilities, recovery/repair, not trampling user-edited text data, etc.

I don't see, why number 3) to 5) are blocked by imminent plans to change the format. Let me go thru them again:

/------------------------------------
If for any reason, the file given on the command line cannot be opened right away:

3) Do not automatically open a new layout.
--> provide a default code path in case of failures/warnings, etc.
This code path does not have to know, what exactly went wrong for what reason. Its task is to help the user gracefully deal with the failure. So it should provide all information, that can be gathered automatically. E.g. the blob of layout data that triggered the failure.

4) Ask the user what to do:
   a) open the PCB anyway
   b) present a help message that gives details on the change of format
   c) quit
--> this is what the default code path should do. b) is only applicable for special cases, where the problem is known at compile time. An example would be backward-incompatible changes in file format. That is, the new version of PCB is known to fail on layout files written by an old version of PCB. If the failure is due to some forward-incompatible format changes, the parser can of course not know what happened. In this case, it still can give the offending lines. This would provide a way for users to ask sensible questions on the mailing list.

5) Make the parser more forgiving. E.g. issue warnings when it hits syntax, it does not understand but don't completely quit working. Yes, this is a pain to implement. But it will cushion the strain on users when pcb format will be bumped seriously.
--> Parser functions should only return ok, if a blob could be processed successfully. Else, it should report a failure to the caller. The caller should then refer to the default code path mentioned above.

IMHO, these tasks, in particular, the last one, should be tackled before a major change of format. This is parser basics, that is obviously not in good shape in current code. The project just got away with it, because there were no major format bumps for a long time.

---<)kaimartin(>---

Kai, I have no problem with anything you're requesting, except that we have very few developers. If you want pcb to have this functionality, the best way to make it happen is to just to it. If you wait for others to do it, you'll likely be dissappointed, as we have other priorities.

Also, in the past I've mentioned wanting to have PCB be smarter about starting new layouts in general - loading templates, stackup wizards, etc. This implies a concept of "no board loaded" which sounds like something your requests would need. Perhaps that would be a good place for you to get started?

#5, btw, we can't do with our current format - anything we don't understand is a hard error, because the format is not flexible enough. We need to separate syntax from semantics to do this one. Solving #5 *is* a change in format.

Can we add a "future-file-format" release target for bugs like this? Probably a lot of the wishlist bugs would go there..