There’s a couple of layers of caching, plus your local cache. I cleared the caches I can control around 60 minutes ago. The changes should take a bit of time to propagate.
I checked the link you sent. It says:
Step 2: Instal KiCad nightly build (currently, version 5.99)
Then gives a link to the nightly builds. The problem is: what are these nightly builds?
I suppose the latest is one of the next versions, but there is no way to know it before installing it.
For example, what version is this?
Is it 5.99, or is it an intermediate version? Right now, the latest stable is 5.1.9, so
I guess the nightly builds can be 5.99, but they could also be 5.1.10 or 5.2 as well.
NB: I will install on a Windows guest running on Linux host. Once I know which version
I should download, it should go smoothly.
Thanks for any hint!
The development version packages which are rebuilt daily/nightly are usually called nightly builds, sometimes daily builds. If the daily testing builds for the stable series bugfix releases is meant, it’s usually stated explicitly.
This is a packaging thing, not a KiCad proper thing, and there’s no official rule for the naming. But you can be pretty sure that if nightlies are mentioned they mean the current active feature development branch (which is now called 5.99 and after the release of 6.0 maybe 6.99) unless context clearly tells otherwise.
The Windows “nightly” directory in the download server is for the feature development builds while “testing” is for the stable series bugfix builds. The latest date is the latest available. The
r<number> is just a running number which has no meaning for the users, it comes from the build server. The last string is the source code commit hash, it can identify the exact version in the git history tree (the same can be found in Help->About version string as
Errors, mistakes or to be enhanced:
you’ll find the introduction of a new format for the schematic and layout files
That’s not true: layout (and footprint) files were s-expression already in v4, I think.
KiCad 6 has a new theme editor.
This passage is a bit confusing because it doesn’t mention colors.
Virtual [sic!] all aspects of the layout and schematic editor are customisable.
Not of course all aspects, but all colors in the work area.
'Nough said. And more small spelling mistakes in this part: “KiCad add”, toobar.
obvious defects (such as the same pad number, and even overlapped their copper areas), but the Footprint Checker did not complain.
Same pad number isn’t a defect, it’s used on purpose in many footprints and is allowed by design.
Here’s an example of a checked defect:
I don’t know what else it would check. I have seen some discussion about this but don’t remember anymore.
KiCad 6 will go through its RC1 and perhaps RC2 iterations until the developer team squashes all bugs and agrees that the 6.0 milestone is reached.
That’s yet to be seen. I have expressed my strong opinions about RC versioning in Yet another release date 6.x question (linked here earlier). We’ll leave this to the core development team, but ATM there’s no indication that the situation would be any different, so there may be many more RC’s before the final. I still hope the name “beta” would be used when the software is clearly still under polishing.
The development team has been trying to be consistent in our naming of the builds. We call the 5.99 builds done everyday the “Nightly builds” and the builds of the tip of the 5.1 branch "testing builds. "
The only reason that we’ve had more RCs than you would prefer in the past is because bugs didn’t get discovered sooner. We are not planning on releasing a RC1 with known issues (at least, serious ones), but the fact is that once we release a RC1 it will get a lot more testing, because of all the messaging in the community to avoid using nightlies for serious work. It’s kind of a catch-22 from the development team’s perspective. I have no doubt that the extra testing that will happen because people who were unwilling to use a nightly are willing to use RC1 will uncover bugs that we will need to fix before a final release.
I still hope the name “beta” would be used when the software is clearly still under polishing.
The meaning of beta and RC are different, and I think we are using RC correctly.
A beta is typically used to gather feedback from users, with the understanding that planned work is still underway and the software is not finished. A RC means there is not more planned work going in to the release. Of course it can generate unplanned work in the form of new bug reports.
These things are not officially defined, but according to https://en.wikipedia.org/wiki/Software_release_life_cycle
A Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs.
A release candidate ( RC ), also known as “going silver”, is a beta version with potential to be a stable product, which is ready to release unless significant bugs emerge.
which is the way I would use the terms.
Right, that’s not that different from what I said. We (the KiCad devs) don’t see the need for a formal beta phase with a release that contains known bugs, given our current resources. So, we take our first RC directly from the development branch when it reaches the level of “no significant known bugs”
You could call the nightly builds “beta builds” by that definition once all the features have landed (so we’re not quite there yet). We just choose not to have a formal “beta” name for the nightly builds at this point.
Sure, I think KiCad follows a fairly ‘standard’ pattern, but is lightweight and effective. It’s worked pretty well to date. It’s a lot improved since the days of official release or self-build. Nightly builds fulfill the role of alpha/beta releases.
I have updated the article with clarification on the installation.
In short, go to the download page, and ignore everything until the heading " Nightly Development Builds". Follow the command line instructions listed in that section.
The Kicad nightly build points to the development branch of the repository, which currently is 5.99. That’s the branch you want to install if you want to play with (soon to be) KiCad 6.
I’ll refresh the article later today as I’m still working on it.
By the way, I have started reading in detail. I spotted one typo in new file format. Bellow should be replaced by below.
This is something that I find difficult to find information about.
Is there any information you can provide to help me fill in this stub in the article?
heh, I still have to write the documentation for it.
Until then, this youtube video is probably a good overview: https://www.youtube.com/watch?v=z6x0xiKgDIc
I think it’s still mostly accurate
Also, wow, it’s been 3 years since I made that video… time flies
Finally, in KiCad 5 Eeschema context menu, the last function is “Close”. I never understood the purpose of this function, since to close the context menu you simply click outside the menu. In KiCad 6, the “Close” function is removed.
This interesting detail actually shows the big difference in the editing model or paradigm between v5 and 6, and was one of the major points in v6 development. I think many people have learned to use v5 eeschema editor, have noticed it’s somehow “weird” or different from other apps but couldn’t tell exactly why. Some people have expressed strong disliking.
It’s because in v5 you can’t actually select anything in the normal meaning of the word “select” in software world. You always act instantly on an item or a group of items.
I hope the next video demonstrates it:
Clicking on an item shows some information about it in the message bar below which may fool you to think that you have selected it. So does the Clarify Selection menu. But what happens after you have clarified the left mouse button click? You can’t open the right button menu for that item which you just “selected”. Why?
Because you didn’t select it. You just acted upon it. You told KiCad to show information about it in the message bar. It’s not kept selected, and when you want to do something else with it you have to clarify again because all clicks do some action immediately.
Doing a drag “selection” works similarly: once dragging is done, the items are acted upon immediately. If you move the mouse they move along. Now it’s possible to use the context menu on those selected items. This is the only situation where they can be said to stay in selected state, and even then they are in the midst of a “move” operation.
Now you can also see why there are two ways to dismiss the context menu. The other discards the selection. The other one keeps it for further actions (moving etc.) or rather goes back to the move operation which was interrupted by the context menu.
This was good in 90’s, but since then every other program evolved and “select first, then choose the action” became the normal paradigm. Even pcbnew has used that normal editing system, so KiCad has been internally inconsistent.
In eeschema v6 the editing paradigm has been changed from the old one to the universally used normal one.
Now it’s easy to understand why this is the most important change in eeschema besides the file format change. Many small new features depend on this fundamental change.
In your context menu screenshots you don’t have icons. Even if that’s on purpose in your GTK setup (or in desktop environment setup) they look cooler with icons for demonstration purposes.
I did not know about that. Cool!
I have turned icons in menu’s of for years and never regarded them as very useful. After I re-installed Linux on a new (to me) PC I decided to leave the icons in the menu’s because I post lot’s of screenshots here and those screenshots look a bit fancier.
It is also one less thing to tweak every time you re-install the OS.
For me (Linux Mint with Mate I think) I can set it in:
[ Main Menu] / Desktop Settings / Interface
Wow, that helps a lot, thank you!
Interesting. I’m using Ubuntu 20.04 LTS. I have not noticed a configuration to turn on the context menu items. I’ll give it another try.