← Back to team overview

kicad-developers team mailing list archive

Re: New pcbnew features and versioning

 

You seem to be confusing backward and forward compatibility...
no

just read my comments from the first mail ...
I always ask to have the ability to save a board with a back release nbr from the new release, if there is not new features on it
... anyway just do what you care

cheers


On 10/04/2016 15.33, Chris Pavlina wrote:
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


References