kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

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     : 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
> >>>>>>>
> >>>>>>
> >>>>>>_______________________________________________
> >>>>>>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