As was found out in another thread, KiCad has semi-supported bezier curves for some time in graphics layers. Now v5.99 can both edit and plot them (previously plotting footprints didn’t work).
KiCad can’t create bezier curves, but if you import them from another graphics format (i.e. DXF or SVG) you can edit them by dragging the points.
EDIT: the fix was taken into 5.1 branch, too. 5.1.5 will plot bezier curves, but there’s some bug left to be fixed for 5.1.6.
This isn’t a “new feature” but definitely “development news”. As many of you know, there has been discussion about moving KiCad development from Launchpad to Gitlab.
Maciej Suminski has done some work to see how to move the bug tracker. See https://lists.launchpad.net/kicad-developers/msg42502.html and follow the second link to see and test the features. At first sight it looks promising.
Project Save As is in. It could use a lot of testing…
Save As was a top ten wanted feature, so this is great news.
(See https://bugs.launchpad.net/kicad/+bug/594051, it’s educating to read also to understand the KiCad project a bit better, if you haven’t familiarized yourself yet with how the wishlist and KiCad development work. You can also see why it can look simple but isn’t and needs a lot of testing.)
Those who compile KiCad but don’t follow the developers mailing list actively must read this: https://lists.launchpad.net/kicad-developers/msg42941.html. Most of you already know that the project has been in the process of moving to gitlab, but now it’s happening for real.
This is already pinned: Symbol Library Editor Changes, but here it is again: as a first step towards new library file format the concept of alias has been removed and inheritance is used instead. Notice that this still works on top of the old file format, so it doesn’t have much features.
I haven’t followed git commits closely for a while, so if you remember something important, please tell it to us all.
But I thought the status of the new gitlab project is worth reporting in this phase. The source code is here: https://gitlab.com/kicad/code/kicad.
The bug database is of course important for all of us. But check also the merge requests. There you can see possible future features which haven’t landed into the nightly builds or the master branch. (Not all of them ever will.) The lead development team can add their commits without merge requests, so it’s possible that most of the merge requests will come from less active or new developers. But I can see familiar names there.
Some highlights (not to say that others are less important) from the current merge requests:
WIP means “Work In Progress”, not meant to be merged in yet but under development.
If you can compile KiCad from git source code you can compile and test the code in merge requests, too. Go to the merge request.
Great overview, @eelik - thank you!
The lead devs will tend to use merge requests to track larger changes we are making, or changes that impact the UI/UX of KiCad (whereas smaller changes / bug fixes tend to go directly in without a MR).
If you are interested in testing merge requests, keep in mind that those marked as WIP might not even compile, or might have serious bugs that could cause data loss, etc, so proceed with caution.
If you pull KiCad code from gitlab you may have received some needless large files recently. See these developer mailing list threads:
Rebase the tree?
GitHub Mirror not updating?
They are likely to be removed from the git history soon which may lead to some complications if people have pulled them. Update your own repos as needed. Especially if you have a public fork. (Again, I’m not so good with git, so don’t ask me for help.)
EDIT: the situation has been resolved (see the Rebase the tree? thread above), the git history has been altered. Simon Richter gave some instructions in case someone has problems: https://lists.launchpad.net/kicad-developers/msg43298.html. The gitlab repo will reject accidental large files in the future to prevent this happening again.
Footprints can have keepout areas.
The v6 roadmap hasn’t been updated for a while, but Craftyjon made a merge request for that purpose.
(The proposed changed roadmap can be found by navigating to his branch and to Documentation/development/road-map-r6.md.)
As you can see in the discussion there, the roadmap may later be moved to some new location with the hope that it would be more frequently updated.
Anyone who’s interested in the future plans should take a look at the epics, too:
Maybe even one of your bugreports is part of an epic. 
It’s now possible to do back-annotation from pcb -> schematic
(It’s not in the nightly build yet, missed it by one commit. Will be there tomorrow. I’ll give a screenshot later.)
EDIT: Available now.
As you can see, it’s quite simple. Just try changing a footprint’s value or reference designator or use “Change Footprint” function and run this dialog from Tools.
The v6 roadmap has been moved to the project’s wiki.
From the new roadmap wiki page you can navigate also to the new v7 roadmap. Everyone is disappointed seeing their favorite feature having been silently moved from v6 to v7 (I was waiting for example teardrops). Let’s hope there’s a good side: v6.0 will be out sooner because there’s less to do.
One point in the V6 roadmap is native net-ties. This will allow be to make RF structures like directional couplers without a page full of DRC errors
I renamed this wiki page to “KiCad Future Versions Roadmap” to be more clear about the purpose:
Right now, the development team is focusing hard on V6 and being honest about what is possible to do in a reasonable timetable. We moved some features from the old V6 roadmap (which honestly was just a collection of every single feature request and improvement that we thought about implementing since before V5), because either there was no developer working on that feature, or because it was seen as too early on to have a good implementation in a reasonable amount of time.
So, it is not that we already know what V7 will look like, but rather that we are making a guess as to what things we can get done with our current resources and a reasonable timeline, keeping in mind that once we hit a feature freeze, our time will be taken up for months by handling bug reports rather than working on new features.
It can always change: we might get new developers contributing, or current developers able to spend more time, etc. I personally think if we are able to release KiCad more often (there will likely be well over 2 years between 5.0 and 6.0!), everyone will be happier, even if each release contains fewer “huge” new features.
One mistake from the roadmaps I made yesterday: due to a miscommunication, the Eeschema Python API was moved off of V6, but actually it is still targeted to V6.
That can actually be a good news, as it makes the V6 a bit more tangible?
Nothing could be worse than an infinite feature+request list for something that would definitely be nothing more than just vaporware.
Little steps, persistence - key to success for such projects
