Yeah, downloaded another nightly build today and all of a sudden the version was changed from 5.99xxxxxx to 6.0 after probably a few years. What’s the reason it’s now 6.0?
It’s 6.0.0-rc1. There will likely be a 6.0.0-rc2, and then a “real” 6.0.0. It just means we’re getting closer…
2 Likes
“RC” stands for “release candidate”. The first candidate is pretty much never shipped as the final product.
Thanks, Jeff, great news!
To be clear, it’s still a nightly build, which isn’t quite the same thing as rc1 (which is a very specific nightly build). All of the nightly builds from rc1 forward will have 6.0.0 as part of the version string (but they are still nightly builds)
When stable v6 is out, will (6.99)nightly building continue in the same location (with the same rate)?
Yes. So, it’s a probably a good idea for many people to switch from nightlies to the 6.0 release, because the 6.99 nightlies will quickly become less stable.
1 Like
Haha, wonderful, is it possible you are making this way more complicated than needed, again, or it’s just for fun? Fun is good! Good luck with the coming 6.0 release, will be exciting to check it out if possible, hopefully with included presets/templates for Gerber and board presets, etc, a version 6.0 which a few seconds later may have the name 6.99? “less stable” is all ok if announced like that, as soon as things are moving in any direction, hopefully some times forward…
If you are just looking at the beginning part of the version text, it will be more confusing. You downloaded it from the nightly build section, so you still have a nightly build.
If you are downloading and installing nightly builds, I think you have some responsibility to be aware of what is going on in the project’s development cycle, that is – right before a major release is usually pretty stable; right after a release is usually pretty unstable as new features start getting added.
Again, you do not have version 6.0. You have a nightly build that includes “6.0” in part of its version string. There is an important difference here that you should be aware of if you are using nightly builds. It is not more complicated than needed, it is important to keep track of the full version that someone is running so that we can tell when they report an issue whether or not the issue has already been solved.
2 Likes
Thanks. That’s all cool.
So, why is that? Why isn’t there a separate 6.0.0-RC1 version available? (I think there should be; presumably automatically updating to RC2 when available, and to the official 6.0.0 when available, no?)
Although Jon is part of the lead development team and I’m not, I disagree with him. Usually in the software world beta1, RC1 etc. are releases. But in KiCad RC1 is tagged and not released as a package which could be clearly separated from other commits coming right after that. On Windows 5.99 and 6.0RC1 nightly builds are a continuum, all under the nightly build download URL. The same is true with Ubuntu etc. At least with Windows the first RC1 actually disappears from downloads when time goes on, and it’s possible it’s not available when the next version is tagged. The version string is applicable to all commits until the next version string change. Therefore I would say that tagging RC1 starts the RC1 phase. It would be different if RC1 would actually be released as a package from a separate directory, linked to from the download page, announcements etc. Talking about one unique RC1 is relevant only when all parties in discussion have access to git using that tag, and that’s not very fruitful when one party is often an end user who doesn’t use git and doesn’t compile KiCad.
There’s also another reason why talking about one specific nightly build is relevant. For other software RC means by definition an exact version which is a ready to be released unless new critical bugs are found. If no such bugs are found within a week or so, the RC is released as is, only the version string is changed. For KiCad RC means roughly the same as beta means for other software, although KiCad RC may be more polished and less buggy than beta versions are in general. KiCad has chosen to deliberately continue with bugfixing phase after the RC tag; there are previously known bugs meant to be fixed before the final release, and new bugs are expected to be found between RC and final.
KiCad project relies on continuous testing, reporting, bugfixing and releasing through nightly builds. Therefore it’s a bit different than software which actually releases beta and RC releases where the version string ending with beta or RC is always applicable to only one specific commit and where testers and bug reporters use those for reference. KiCad encourages using always the latest nightly build for reference.
RC1 is tagged by the development team, but the releasing as a package part is up to the packaging team. I know packagers are working on this, and some might already be available.
The RC1 that you could grab from the Windows nightly folder is not an official RC1 package. There are no official RC1 packages for Windows or macOS right now, because neither of the packagers for those platforms have made one yet for various technical reasons.
The reason we don’t link to a RC1 from the downloads page is because there aren’t packages ready yet…
An actual RC release would have a version string ending in rc1 rather than it appearing in the middle and also including a git hash.
1 Like
If that’s happening I take back my words. I just haven’t heard about this before. (Edit: or probably I haven’t interpreted what has been said correctly.)
In any case, releasing an RC (as the term is used now) is not without problems. People will use it for reference when finding and reporting bugs, but bugfixes are released every day with nightly builds. This may lead to duplicate reports especially because reports are closed immediately when they are fixed.
Not a big problem, I think, but worth noting when we talk about KiCad development and release model.
This tradeoff is one we are OK with. The idea is that more people might be willing to try a packaged release candidate than to try nightly builds. We accept that people who install this RC package might not just want to install the next nightly build every day. It’s a tradeoff between getting more testing and managing duplicate bugs, and at this stage, getting more testing is important.
2 Likes
Exactly. And because I can janitor the bug database, I should pay more attention to it between RC and final…
To be fair, we made zero announcement.
I have yet to even begin work on packaging a RC1 for windows, it’s going to be quite some time for me to figure out jenkins for this.
1 Like
Wonderful, this is just getting more and more simple/clear… 
Assuming you are being sarcastic: the simple and clear approach is to just use the released version of KiCad. If you want to use nightly versions and help test / prepare for a release, there is (a little bit) more complexity that you have to learn about. I don’t see much way around that.
5 Likes
The world is usually not as simple as we might wish — Me