Now we have the problem with confusion about Nightly versions again.
Do we have the server space now to allow both V6 development branch Nightlies aka Master and the 5.1.x tree? Right now I am more interested in what will be future 5.1 point releases.
Some sort of clear directory identification is needed
2 Likes
The confusion for new KiCad users to understand what version they are using is very likely to keep getting worse.
How about 5.1.0-071 instead of the above mess?
The “071” is today’s Julian Date with a leading zero so that it is always three (3) digits in length.
And, perhaps add a second string in the middle, such as…
5.1.0-id-701
5.1.0-rc-701
5.1.0-tg-701
The string
“id” - Initial Development; as in starting a new branch
“rc” - Release Candidate; as in just about to tag a branch
“tg” - TagGed release; waiting for everything to catch up before announcing Official Release of version.
This would be very easy way for forum members to answer questions that have different answers based upon the version of KiCad that is being used at the time.
Only bugfixes as always with minor releases. Meaning no need for nightlies here.
The above “mess” is the git commit hash. (The reason the hash is used instead of the day is because there is more than one commit per day. This is the only way to uniquely identify git commits with a single string of numbers.)
I also seem to remember that there was the string “dev” somewhere in the name in the past. This was to make it even clearer that the version is a development snapshot not a release. Has this gone now?
Using nightlies requires users to know what they are doing to be honest. They are meant for testing the software and giving feedback. They are not for productive work. (As explained in my FAQ article)
Yes i know the nightlies have been quite tame for a while. But that was an exceptional period. Now we will again get the problem of no more forward compatibility.
I would not be expecting a new 5.1 fork build every day, but GitHub activity of cherry picked
bug fixes is going to be quite significant when 5.1.0 actually gets formally released.
Past experience tells me that we will probably be on 5.1.5 by the time a true 6.0.0 rc1 appears
They can selectively decide to publish nightly builds or at least rc’s for point releases if needed. All changes which go to 5.1.x should be in master development branch and nightly builds already before they are in the point releases (unless something has been changed so radically that a fix to a point release can’t apply to master development).
Once the schematic changes for 6 start, v5 bug fixes are likely to NOT be in master
I am quite sure the v4 bugfixes where cherry-picked (*) from master and not specially developed just for v4. (After all a bugfix for v4 is likely to be needed for v5 as well. I would guess something similar will be true for v5 fixes and v6.) But you might want to ask over on the mailing list for details about something that deep into the development workflow specifics.
*) cherry pick is a powerful git command that can take a single commit (or a range of commits) from one branch and apply it on another as a new commit.
Hi, it would be nice to have snapshots of KiCad 5.1x in order to see if the tool crashes less often than 5.1 does.
It is important to fix bugs and have a tool operating rock solid while lacking some cool features, as many people want to use it in the production environment of a medium sized business that was e.g. using eagle and wants to escape the vendor-lock-in problem.
Here a stable KiCad would be a nice asset in order to sell the use of OpenSource tools to CEO level.
I use KiCad at the moment only at home or for students who want to do small student projects to gain practice. Would be nice to have a rock solid eagle replacement.
Cheers,
Xennonflash
There will be releases on the 5.1 branch in a regular period (I expect about two per year with a few more in the first year.)
Case in point: 5.1.1 will be tagged shortly meaning we will see this release within a week or two. https://lists.launchpad.net/kicad-developers/msg40077.html
Cool!
And dont wait for docs. I prefer a more stable kicad to better documentation, as the changes will not be that big from 5.1 to 5.11 but having less show stopping bugs is a big asset.
Cheers,
Xennonflash
The kicad release policy is as it is. Everyone involved gets a chance to have their updates included. Accept it or learn to compile it yourself.
Ok, where to find the howto and the build environment for windows?
I know the answer RTFM, but maybe, you can give me a better hint.
https://lists.launchpad.net/kicad-developers/msg40087.html
The idea is that when the package split then finally happens, we can use
these GUIDs for the separate parts, so users can go back from a split
nightly to a 5.1.1 release just by installing over the nightly, and it will
install cleanly without file conflicts.
Looks like something similar to what you have in mind is already in the works.
More importantly, is that 5.1.2 should be released in the next couple of weeks; likely fixing the crashes you have experienced.
The Version 5 releases seem to have been buggier than before, but that could simply be due to the increased number of new users using the more advanced features.
Earlier there was a great thread about how well KiCad now behaves overall:
I would not hesitate to recommend KiCad for most design work. I really look forward to the future of KiCad in the workplace.
Point releases will be just bug fixes, mainly critical ones.
They should generally have no effect on documentation as none of the Master branch changes that cause any file format change are allowed…
When attempting to run build_all.bat in a 32-bit environment, I get a hash mismatch error for msys2-base-i686-20180531.tar.xz (I get b2ef7b785e49e5cec9de908c033107b5 where d41d8cd98f00b204e9800998ecf8427e is expected according to the batch file).
I tried downloading several times with the same result (http://repo.msys2.org/distrib/i686/msys2-base-i686-20180531.tar.xz). Is it me or what ?
It is not about updating the documentation to get it to fit to a new interface but including fixes made to the docs since the last release.
Regarding Altium:
The sales of Altium claim that they can also read the text format of their own protel tool for DOS, so it would be interessting to get a valid format description to be able to read altium schematics and also to export to altium schematics, so one can use the pcb tool of altium, as it should be better for high speed design according to the claims of the manuf.
Also it is good to help altium users to escape vendor lock in.
Do you know where to find the altium format description? The sales dept claims that users can script in Delphi(!) and dont need the file format, but for longevetiy of designs and using revision control systems a readable and parsable file format is required.
Has anyone experience with the altium formats and some ideas on how to write an importer / exporter altium2kicad?
Ok, I found it:
But still is the tool usable and is there a format description of the altium format?
The https://kicad.org/external-tools/altium2kicad/ tool is a good start but should be rewritten to become part of KiCad, as the Eagle2KiCad import.
Regarding Eagle:
As the new owner of Eagle changed to a subscription “software rental” mode that wants to communicate with the manuf in order to check the license state (and leak some data?), users of eagle get pissed, especially if they want a stable investment like buying a bike and having it instead of renting a bike.
So we can use this momentum of unhappy eagle users to pull them to kicad and make them donate money when they are pleased with it in an production environment.
But the prerequisite is rock solid operation and stable import of eagle designs. Best would be a batch import of all eagle designs in a directory, while having a name space for the endings, as mentioned before, like kicad_ in order to avoid chaos when doing a batch import.
When we manage to satisfy former eagle users the kicad project will gain much momentum.
I for example test KiCad with small stuff in order to prepare the gradual migration a small HW R&D dept. to KiCad once it is really stable and at least as good as Eagle 6.X. Stability is a must.
No more issues with licensing and student projects. Just dowload the tool, develop, contribute here and there and having a great time developing with a free-as-in-freedom EDA tool.
This would be very pleasing to know that any contribution gets into freedom and light and not into the dark vendor-locked-in world of mordor.
Cheers,
Xennonflash
1 Like
I highly doubt that you will be able to find an official source for that. Altium simply has no benefit from publishing something like that.
Wow. Already… I missed 5.1.1. 
(Teasing you for a typo.)
1 Like