That’s an interesting metric, but rather hard to get a number on. I guess you would have to make a test release, then do a survey to see how many people noticed any changes. Then decide what percent “most” is.
I generally don’t like programs reporting back, but it would be pretty interesting feedback to see how features were used.
I am waiting to see an update on exactly what 5.0 will feature and what is left to add before the freeze.
Hi Joan,
I too were using nightlies always ( now Jan build) and thought of updating to latest when current board is finished.
what is with nightlies from March, any issues?
@dchisholm or @davidsrsb or @bobc, can’t remember who it was wrote here some weeks ago that the ones from Jan/Feb were good after I had trouble with the ones from begin of March I think (can’t remember what it was, but some basic stuff didn’t work), so I took one from back then (after having upgraded some nightly from Nov/2016).
I’m currently running this one and made two simple boards with Elecrow, no problem…
Application: kicad
Version: (2017-02-10 revision 1bcbbb4)-makepkg, release build
Libraries: wxWidgets 3.0.2
libcurl/7.51.0 OpenSSL/1.0.2j zlib/1.2.8 libssh2/1.8.0 nghttp2/1.16.1 librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.62.0
Curl: 7.51.0
KiCad - Compiler: GCC 6.3.0 with C++ ABI 1010
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=OFF
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_SCH_IO_MANAGER=OFF
KICAD_USE_OCE=ON
February was when some major library handling and footprint selection code was merged. Since then a hive of bugs has bitten. A lot of them are still there, far too many stalls and crashes for a release currently
I have made comments like that about nightly builds over the last week or two. They were peripheral to other discussion topics so I can’t find them quickly. @Joan_Sparky is running the same release I am currently running (on three different Win7/64 machines):
[quote] Application: kicad
Version: (2017-02-10 revision 1bcbbb4)-makepkg, release build
Libraries: wxWidgets 3.0.2
libcurl/7.51.0 OpenSSL/1.0.2j zlib/1.2.8 libssh2/1.8.0 nghttp2/1.16.1 librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
I reverted to this release after I discovered that a nightly from about 14 Feb was corrupting library files. I have successfully used it on several layouts - pretty mundane stuff; 2-sided through-hole assemblies (although one has a pretty high component density). This release crashes about once or twice a week on me but I can’t seem to isolate the exact circumstances; it also may be isolated to one machine in particular so KiCAD may not be entirely to blame. When it crashes, all I lose is work in the buffer since the last “Save”.
Dale
I have just found a really nasty bug that silently breaks nets, see https://bugs.launchpad.net/kicad/+bug/1677282
This is a simple project that demonstrates it.
All I did was draw four parts on the third level of a hierarchy, get the resulting pcb footprint connectivity that I expected and then substitute a part.
recoverybug.zip (14.0 KB)
A 4.1 release cannot be based on this sort of foundation
It looks like you found it in the most recent nightly build (29 Mar 2017). Anybody have guesses how long the bug has been lurking in the background?
The bug report says,
" . . . Then I deleted F1 and replaced it with a new F1, different symbol but same footprint . . . . "
I assume you :
Dale
I opened your project in my nightly build from 10 Feb 2017. This is apparently the project after @davidsrsb replaced the F1 symbol and found no connections in PCBNew. The diagram in EESchema passes the standard “Is it connected?” tests. However, the ERC in EESchema doesn’t see any connections to F1, nor does the ERC tell you to flag F1 with a “No Connect”. Visually scanning the netlist in a text editor confirmed that no connections to F1 are mentioned in the “Nets” section.
I substituted a different (known good) fuse symbol from my local library, and generated a new netlist. The netlist shows proper connections to the pins of F1, and creates the expected ratsnest when it is loaded into PCBNew. Apparently, the 10 Feb build does not have the bug when it uses my local symbol for F1.
I reverted to the original schematic as supplied by @davidsrsb . I generated the netlist with my 10 Feb build. The netlist does NOT have entries for connections to F1.
My WAG is that the problem may be in the definition for the F1 fuse symbol, rather than KiCAD itself. The other possibility is that there is a VERY ancient bug in the netlist generator.
Dale
Sorry Dale,
What’s the meaning of WAG?
A guess or estimate based on a hunch or intuition, with little or no supporting data to give it credibility.
Dale
When I think about it, many of my SWAGs have turned out to be correct…
Wayne noticed I was on a 10 mil grid, so I tidied up to sit on a 50 mil grid.
Now one pin connects, but ERC shows no connection to J1 pin 2. No boxes showing and the dragging test passes.
I am wondering if the fuse symbol somehow breaks things (the centre line perhaps?)
recoverybug.zip (14.0 KB)
edit
A “C” capacitor symbol does the same thing
Let us actually LOOK at this thing…
I actually read the post and watched the YouTube videos on NET issues today.
I have a screen shot, but this “described” issue has nothing to do with the heriarchy of the board. It is a “trick” with the NET names.
I’m not certain what “trick” this schematic is exploiting; but I do know that if you REMOVE all the NET labels the issue goes away.
Like this screen shot:
It remains a very wonky schematic that likely doesn’t actually do anything other then blow the fuse upon connection to the outside world. 
It’s nothing to do with hierarchy
It happens when you use manual annotation after substituting a component.
Running “Annotate” after wards fixes the error
Looking at the schematic file I see that Annotate silently changes a “0” to a “1” on two lines
$Comp
L C C1 (Component is a “C”, reference “C1”)
U 0 1 58DC707A —> U 1 1 58DC707A
P 6600 3700
F 0 “C1” H 6715 3746 50 0000 L CNN
F 1 “100n” H 6715 3655 50 0000 L CNN
F 2 “” H 6638 3550 50 0001 C CNN
F 3 “” H 6600 3700 50 0001 C CNN
0 6600 3700 ----> 1 6600 3700 (the coordinate of the centre of the substituted part)
1 0 0 -1
There were a few of us devs who suggested a “4.5” or similar before too much refactoring had been done just so stable users could get some of the latest toys, but we were also told that 5.x won’t be long off so there would be no point. I guess that means people have to wait until Christmas to get their new toys. There’s no way we could make an intermediate release now; there are too many big changes which require testing.
The value that changes is the unit number, I think for single unit symbols the value should be 1.
Using the manual annotate “U” command on 4.0.6 immediately sets the value N to 1.
Looks like we have a bug here.
There is nothing worse than a netlist generation error, nothing downstream like DRC and the PCB electrical test will flag it until you end up with a batch of non working boards. This happened to me 10 years ago using Orcad on a 6 layer BGA board, very expensive scrapping and 3 months of project delay.
