Released.
Does anyone know if/how can I see summary of updates?
I know in general its “bug fixes” but I’m hoping for something more concrete…
M
, How did I miss that 
?
Probably you won’t get anything similar till release 5.
Anyway, having a better 3D library with models with right material properties would help in a better 3D rendering result
That would be a need also for the new rendering engine…
M
1 Like
I just downloaded 4.0.3 and it seems to now fail on File-open on every instance of roundrect ?!
Application: pcbnew
Version: 4.0.3-stable release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.2.0,wx containers,compatible with 2.8)
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Boost version: 1.57.0
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
USE_FP_LIB_TABLE=HARD_CODED_ON
BUILD_GITHUB_PLUGIN=ON
eg
(pad 11 thru_hole roundrect (at 3.81 -3.81 270) (size 1.4986 1.4986) (drill 0.889) (layers *.Cu *.Mask)(roundrect_rratio 0.25))Perhaps roundrect feature didn’t make it to the 4.0.3
I’d suggest using development branch
wow, really ?
The June 19th release I was using was fine on those, and I thought roundrect was in before that …
Well, the blog post says:
The stable release version 4.0.3 is made from the lp:kicad/4.0 branch with bug fixes and improvements cherry picked from the development branch of KiCad.
And roundrect feature might not have been cherry picked. You can always check 4.0.3 branch logs to see if that’s actually the case. But personally I don’t bother with stable releases as I haven’t experienced any major problems with the development branch but other people might have different experience.
1 Like
And the CvPcb search box?
I actually run several PCs on 4.1.0 alpha from nightlies and just one on stable release so that I can check on forum questions.
Life gets complicated explaining things to new users when a lot of the debate in the forum is about features they don’t have. I’m also not too happy about so many of us vulnerable to a badly broken nightly breaking something critical -alpha releases carry a health warning
Hmm, ok, so then the question is which is best to use, as I do need roundrect for testing,
Is 4.1.0 ‘too alpha’, and should I just use the newest 4.0.x development build ?
4.1.0 alpha is very stable in my experience since it first appeared.
It is unofficial, so the PPA might vanish at any time - the server bandwidth used must be quite high.
As it is “alpha” it might get an interesting bug that silently corrupts some important projects - using this version a backup policy is definitely more important.
I need the rounded rectanglular pads for some connectors, where replacing the default square pin 1 pad allows routing around the pad much more easily
1 Like
google cannot find a win64 build of 4.1.0, so that may make the decision easy.
Meanwhile, I downloaded r7005, and try that. Looks all ok so far.
Installing 4.0.3 Win64, you have to deselect German, French etc Help files.
Otherwise you waste over 100MB of disk space
1 Like
Roundrect won’t be ported to the stable branch since it requires changes to the file format. Like many of the new toys added since the release, it will have to wait until V5.
1 Like
The entire 3D plugin system + new 3DViewer was a huge job; I was working on part of it for about 10 months and Mario was working on it for about a year (maybe more). The changes are too big to justify a backport so I guess the best we can hope for is an early V5 release.
3 Likes
No CvPCB search either. 
I really hope a major upgrade can happen in the next 12 months.
A lot of the bad press pre 4.0.0 release KiCad used to get comparing with Eagle, was down to the previous 2013 release being the default for far too long
I’m absolutely ecstatic that there even is a v4.0.3 release! I joined the party back when I had to compile KiCad myself. Since then the project has progressed and also matured in leaps and bounds. To the dev team and core community, thank you all for your hard work. You have created a fantastic enabler!.
I have a couple comments on the theme of documentation. They’re from the perspective of a “Windows” user[1] (take from that what you will. 
).
It seems to me, that as the KiCad community grows (as with any community), consistency, clarity, and ease of access to information on terminology and workflows will help new members assimilate more readily into the community, and mean core team members will have fewer questions to answer and more time to work on core issues (or to just enjoy life outside of KiCad a bit more).
-
I think it would help new users (and older users with bad memories) if there was a notice on the download page indicating how to upgrade. I’m sticking to stable releases and every time I upgrade I wonder if I’m supposed to uninstall the old version first, what happens if I don’t, and whether (and how) I can keep the old version around for a while if I want to. Fwiw, I figure I’ll probably never go back and let the installer over-write, but I still wondered if old files remain as-is unless overwritten).
-
I think it would help everyone if the Community >> Developers website page was expanded to describe the release engineering process. For example:
- How are version numbers determined? What specifically is meant by “alpha”, “beta”, release candidate (RC), etc.
- What is the development workflow and how are branches used? How specifically does a) a new feature development and b) a bug fix enter the codebase, get merged between branches, and eventually be released (or not). The explanation for the origin of 4.0.3 in the release blog post was very clear, and perhaps could be generalized as the rule. However, it’s not clear if “4.1.0 alpha” is a real thing or not because I don’t see a “4.1.0” branch in the KiCad Launchpad repo. Is “4.1.0 alpha” the colloquial name for the head of the 4.0 branch? I also don’t see the “4.0.3” branch for the “4.0.3 branch log” referred to by @cioma (should this be “4.0.3 release log”?) I’m playing devil’s advocate here a little because I’m sure this makes perfect sense once you’re into the project deep enough, but I think it demonstrates the potential confusion for new community members.
Pictures are great, both from the perspective of non-native-english members and because reportedly no one reads text anyway - or only as a last resort. I found the graphics in Vincent Driessen’s “A Successful Git Branching Model” blog post very clear to follow. Although I think GitFlow is not for everyone, something similar could be very helpful to developers and technical users who are encountering KiCad for the first time to quickly understand the over all process.
I don’t see the stabilization and release branches in the Launchpad repo that I’m familiar with coming from git and subversion projects. I readily admit I’m not familiar with the Launchpad workflow, and expect I could find some recommended practices in the Launchpad docs, but also expect they would not be specific to how KiCad uses Launchpad. What is the process by which it is decided that a new branch must be created in the Launchpad KiCad repo? Are branch names simply what I chose to create for a local dev branch, and accepting my bzr push by a dev team member creates the branch in the Launchpad repo (and who I guess also takes on possible further integration and testing?)
It could also be very useful to the broader community to have static list of major new feature developments that are underway - essentially a medium-term high-level roadmap for the project, giving the name of the branch and when the code is expected (hoped) to land in a stable release (if at all). At some point the details are in the code (and the dev mailing list, and the forum) and it’s not worth the effort to further document, but a high-level list, updated semi-annually at most, could help solidify the community by providing a guiding influence, and increase confidence to new members by demonstrating a strategy and plan for the future. The overview might also help address the concerns of @davidsrsb, by providing a context for new feature discussion in the forum.
Cheers!
Dale
[1] In the late 80’s I first used OrCAD and P-CAD on a PC-AT clone, then Mentor Graphics on Apollo Aegis (unix) workstations, and used Viewlogic in the late 90’s for Xilinx 3000-series projects. Since the 2000’s up to recently, it seemed everyone I worked for used Protel/Altium. Now that I’m on my own, I see no reason to use anything but KiCad on Windows, although I readily admit I’m also not currently pushing the envelope with corner cases (Windows is the convenient common denominator for the variety of software I use daily, it’s BSD for servers!).
Thanks for all the info and discussion!
One small question - in the change list I see:
“-Pcbnew: loading file with footprint on an inner layer causes an assertion.”
I read the bug report it refers to. So… does all this means is that Kicad still doesn’t allow Footprints with pads in inner layers, but at least now spits a proper error report?
Are inner layer pads planned to be supported?
Tnx again!