kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 4/7/2016 9:47 AM, 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:

JPs rounded rectangle commit is a problem.  I did not have a chance to
review JP's patch.  I would have recommended a file version bump.

Angled text support should not be a problem.  Text angles are already
saved as floating point numbers so using angles other than 0, 90, 180,
and 270 should not cause any issues but that hasn't been tested.

> 
> 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.

Older versions of Pcbnew will fail to load because the new board file
rounded rectangle tokens are not supported by the stable release board
file parser.

The angled text may be more problematic because the file will load but
what happens when the text displayed may lead to some interesting results.

> 
> 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.

Makes sense to me.  Warning the user that the file may not load in
advance is probably more friendly than the file parser error that will
be displayed when the file fails to load.

> 
> 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.

I will merge it into the stable branch when it's available.

> 
> 3. Adopt a policy of properly bumping the version number any time a feature is
> added.

I agree that adding new features should bump the file format version.
Whether we should do this for once each feature or once each development
cycle is debatable.  I tend to lean towards each feature but we should
coordinate file system changes and attempt to make changes to the parser
and output formatter in bulk even if we do not implement the features at
that time.  Otherwise we could bump the file revision multiple times
during each development cycle which could get annoying depending on the
frequency of file version changes.

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