I thought many would be interested in the development status and new features of pre-v6/post-v5 now when 5.1.0 has been released and version 6 development has begun. Add your favorite here if someone else hasn’t done it already.
Note: at the moment the developent versions are named “5.1.0-n-g…” (where n is some number) instead of the older more misleading “6.0…”.
EDIT: This thread is about the ongoing feature development for the future v6, not for bugfix releases in 5.1.x series.
Chamfered pads.
“Chamfer size” 29,3% seems to be close enough to make an octagon.
This feature is apparently not compatible with v5, so if you use it you have to stay in nightly builds. It’s like rounded rectangles were for v5 after v4.
Edit: this is also possible with chamfered pad because it has also rounding, actually it’s like a rounded rectangle + chamfers.
The more powerful bus handling will also be a good addition.
But to be honest the feature i await the most is the new schematic and symbol file format. (And yes i am aware that it will take a while till we get that one.)
For information, where did you get such a nightly with this dvpt feature ? The latest I get from https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/ is still tagged as 5.1.0-9-blah (project manager) and 5.1.0-rc2-47-blah (eeschema and pcbnew).
I pulled from git master and compiled on linux. If not yet there, it should be in the next nightly build.
Edit:
2019-03-11T23:37:50.290Z 898.9 MB kicad-r12510.c61ec8ee3-x86_64.exe
This is 5.1.0-9-gc61ec8ee3. The version number scheme was changed when v6 development started. It’s a bit better than 6.0-…, at least it doesn’t give impression of v6 which is probably some years in the future. Personally I would prefer 5.1.0+n…, it would be a bit clearer, or maybe 5.2 (which would then be reserved only for development).
Unless I got an install issue, the nightly you’re pointing to has the project manager as version 5.1.0-9-gc61ec8ee3. but eeschema, pcbnew, 3d viewer, etc. are 5.1.0-rc2-47-g6eb84e42f which is a bit confusing. Anyway, no chamfered pads in this nightly. Will wait next night 
BTW, the symbol library browser doesn’t display any version information when using Help / About eeschema… Probably a bug.
Everything works properly for me with that nightly build, including chamfered pads.
(Could some admin take this issue discussion to a new thread?)
7 posts were split to a new topic: Does it make sense to have development snapshots for the v5.1 branch going forward?
A post was split to a new topic: Feature requests: Colored tracs and better eeschema and pcb new integration
People, please, don’t share feature request in this thread! There’s a whole dedicated category for that. The usefulness of the thread diminishes considerably with offtopic posts because this will be a long thread and updated with new features along time, at least if I or someone else will have time to follow the development and report about it. Ideally someone could read the whole thread after using 5.1 for a long time and catch up with the new features. Noise would make it tedious.
Hatched filling for zones has been merged. I just compiled and it looks nice:
The screenshot is only a quick example, I won’t use it in this case, maybe I never will use it. See e.g. https://electronics.stackexchange.com/questions/5139/solid-ground-plane-vs-hatched-ground-plane for some opinions. Flexible circuit or impedance control may be good reasons to use it.
Smoothing means rounded/chamfered corners:
EDIT: the feature itself is of course incompatible with earlier versions, but if you don’t use it, the file should be compatible with earlier versions.
This has been merged. Until it’s available in the next nightly build, the new documentation is here: https://github.com/KiCad/kicad-doc/blob/d27c4009275d2801da932cf0d0dfdccd4448ed58/src/eeschema/eeschema_schematic_creation_and_editing.adoc
I haven’t used buses so I can’t comment. Someone else could tell what are the differences between old and new.
The main usefulness of buses always was for using them to connect over hierarchical interfaces. The old bus could have a bus pin of the form bus[0…9] Which meant that single pin represented a parallel bus with indexes 0,1,…,9. As far as i understand it the new bus can define more powerful buses (for example a SPI with signal names CS, CLK, MISO, MOSI)
If you did not go over a hierarchical interface then buses in the past where simply graphical lines that showed users connections between local labels in a clearer way.
The new bus features will also add power to this usecase. (proper bus entry and exit via the alias and unfolding stuff)
I do not know if buses can now also go via global labels. (Nor do i know if this was possible in the past.)
If you look at your linked document then the vector bus is what has been available in previous versions. The group bus is what is new. (With all the tools needed to properly handle such a bus. Meaning bus unfolding and bus alias handling are also new.)
Another new thing is connecting two buses with each other. I am not sure how much got into this implementation (I think this was one of the topics that created problems during the implementation phase. Might be that there where feature reductions here. I don’t really see a detailed explanation in the document so it really might be something that got removed.)
Dry run for Cleanup Tracks and Vias was merged last week.
Test Footprints functionality was added to DRC last week.
Curved ratsnest lines were added last week.
Thanks Jeff.
Can you (all) tell what is connected?
(Right now it’s available only in the left hand toolbar and in a strange location. IMO it should be near the Show/Hide Board Ratsnest, and it’s called “airwires”. Also I suppose it will be available in the View menu in the future.)
Thanks for that feature goes to “blubberbub”. I’m only the messenger.
I dropped this feature and will clarify this in the docs once the dust settles on all the bug fixing.
In addition to adding new bus features (like bus groups and unfolding) the entire connectivity/netlisting system got overhauled, which means some other neat things are coming soon 
As part of that overhaul, I needed to clarify some of the “rules” for how net names are assigned and how they propagate / override each other when you use global/local labels, hierarchical sheets, etc.
The docs for this aren’t done yet but it’s on my todo list. I think the end result will be a more predictable behavior although in a few cases it will be different from what KiCad used to do.
EMS field solving with external tools, see Kicad nightly (development snapshot of future v6) can export to the format Hyperlynx.
