On Sun, Apr 10, 2016 at 03:30:15PM +0200, easyw wrote: > >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. ;) > so this is as I thought... users point of view don't count so much > > >4022 is _old_. If you're still using it, upgrade. > I was pointing out the case of 4022... not saying I'm on 4022 (still I have > old projects done in that release) > > If I remember correctly also Tomasz suggested to have a back compatibility > when the new stable came out (there was a problem on new layers added to the > new release), to help users smoothing the change
You seem to be confusing backward and forward compatibility... > > I'm just saying that if a board doesn't contain any new feature, can be > saved as old (as few days now) release version... > > > > On 10/04/2016 15.10, Chris Pavlina wrote: > > 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
