kicad-developers team mailing list archive

[easyw <easyw@xxxxxxxxxxxx>]

> 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

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