kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

>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