Does it make sense to have development snapshots for the v5.1 branch going forward?

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://github.com/KiCad/kicad-winbuilder is the simplest option.

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. :wink:
(Teasing you for a typo.)

1 Like

Maybe, you can make them publishing it with the same argument M$ was forced to standardize and document their complicated XML file format.
Libreoffice / Openoffice has a good well documented format which made it first through the standard bodies.

So if you play config management the hard way you want to be able to generate the artefacts from source files even when the tool vendor does not supply the tool anymore. With well documented data formats, one at least in theory is able to throw money at the problem and to hire people to code a converter tool to be able to import old designs.

If a party really insists on file documentation or otherwhise would not buy 42 seats of the tool, I guess the vendor would move.

Cheers,

xenonflash

No, that is to generous. That was a genuine brain-fart; caused because it is normal for humans to start counting at “1”; not “0”.

Yeah, I bet that even the two-year old son of @AdmiralCrunch knows that! But Analog Artisans graciously tolerate creatures from the software and digital realms. Well, at least most of us do.

Dale

1 Like

… and realize, that I can count on my fingers up to 32 on just one hand. So, is the guy in the image actually trying to inform the viewer that the correct number is “4”?

1 Like

Depends on whether it’s little-endian or big-endian format. And, of course, being a photo there’s the question of mirroring.

Dale

I think you confused “most significant bit (MSB) first”/“least significant bit (LSB) first” with big endian/little endian.
The former defines the bitorder in a stream of bits. The later defines the byte order in a stream of bytes. (big endian can have both MSB or LSB first ordering so does little endian.)

1 Like

Actually, the 5 bit binary number for decimal 4 is a palindrome (00100). So bit order doesn’t matter. :nerd_face:

1 Like

@Sprig, @Rene_Poschl, @SembazuruCDE ;
When I laughed at these last 6 posts, my wife wandered over to see what was so funny. She barely comprehended the humor even after I explained it. (She DOES recall the word “palindrome” from when we played around with them a couple decades ago.) It mostly reinforced her belief that “Engineers make rather decent husbands, but you don’t want to be caught dead with one at a party.”.

Dale

3 Likes