>From what I've seen of the forums, the users complain about _everything_, I don't think it's necessarily our job to minimize complaints. ;)
4022 is _old_. If you're still using it, upgrade. If you're still running Ubuntu 320BC.06 and it doesn't run, upgrade that too. :P On Sun, Apr 10, 2016 at 03:05:14PM +0200, easyw wrote: > >I don't really see much reason to care if 4.0 can emit board files 4022 can > >read. > 4022 was considered STABLE for very long time, many users didn't want to > move from there for long time... > Now the 4.0 is the 'new stable' release and a lot of users will not switch > to the new for long time (till next stable)... > Adding something that cannot produce backward compatibility IMO is just > something that users will complain about... (have a look at the forums if > you care) > Moreover that would be just checking if some of the new feature scheme is > implemented on the board file and the warn the user in that case or just > downgrade the version if everything is as usual (as Wayne already pointed > out in a previous message) > >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. > > Maurice > > On 10/04/2016 14.56, Chris Pavlina wrote: > >The upgrade from 4022 to 4.0 wasn't as smooth as it could have been, no. But > >tbh I don't really see much reason to care if 4.0 can emit board files 4022 > >can > >read. Upgrade to 4.0. It's KiCad, not Altium, it's free. You can upgrade. > > > >Now, if 4022 emits files 4.0 can't read, that's a separate problem, and not > >really relevant here. > > > >On Sun, Apr 10, 2016 at 02:51:41PM +0200, easyw wrote: > >>>This gets filed under "things said by people who haven't seen what'd be > >>>necessary to implement that" ;) > >> > >>This gets filed under "things said by people who cares about what user's > >>need in a real production world" > >> > >>If you don't care about what happened with the 4022 vs new stable for users, > >>then it is fine for me ;) > >> > >> > >>On 10/04/2016 13.59, Chris Pavlina wrote: > >>>This gets filed under "things said by people who haven't seen what'd be > >>>necessary to implement that" ;) > >>> > >>>On Sun, Apr 10, 2016 at 10:23:22AM +0200, easyw wrote: > >>>>I think there should be an option to export a new board version to > >>>>previous > >>>>version, eventually warning on what could be lost if the file contains > >>>>some > >>>>new features... > >>>>that is a standard feature in most sw, to allow a better collaborative > >>>>environment > >>>>Maurice > >>>> > >>>> > >>>>On 10/04/2016 02.49, Chris Pavlina wrote: > >>>>>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 : [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 > >>>>> > >>>>>_______________________________________________ > >>>>>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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
