kicad-developers team mailing list archive

[Simon Wells <swel024@xxxxxxxxx>]

the problem is you are dealing with potentially very close tolerance.
and numerous other issues that if htere is a compatibility possibility
we will probably get people saying that compatibility breaks their
design. There comes a point where it just has to be dealt with, a save
with compatibility could/would change rounded rects (and when added
polygonal pads) to rectangles that may then breach design rules so
that would need to be taken into account getting quickly to the point
where you may as well just redo the whole board as in its current
state its useless

On Mon, Apr 11, 2016 at 1:05 AM, easyw <easyw@xxxxxxxxxxxx> 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
>
>
> _______________________________________________
> 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