Le 07/04/2016 17:52, Wayne Stambaugh a écrit : > 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.
It can be done now. This is not too late. Just I need to know if the new version is 5 or 4.1 (adding rounded rect pads is a minor change, because the file format does not change when rounded rect pads are not used) For me, a major change is more when new features are always stored in file, and the file can be never read by older versions. > > 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. I tested that and did not see issues. (AFAIK, the text rotation is fully supported by Pcbnew because the footprint rotation (therefore the texts rotation) is defined in 0.1 degrees). > >> >> 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
