Any chance of a higher release cadence? Say, a major version every year, with relatively fewer features

KiCon KiCon 2020 Questions
19

In a perfect world you don’t need a lot of GUI testing. In such ideal situation GUI event handlers are a thin shim translating GUI events into internal business logic data and method invocations. Then you unit test your internal logic without the GUI cruft and write simplistic tests for GUI event handlers with mocks for internal logic to cover the translation code and bam!, you have full test coverage.

Problem is KiCad is far from perfect in that regard, there is no clear separation of business logic and GUI code.
And that’s not something a newcomer can solve, this needs discipline and clear directive from project leadership: move toward testable code and add tests.

I strongly disagree with the last part here. Right now gitlab pipeline takes more than 3hours to run and it only does a linux build.

Imagine for a moment that every time you push a rev to a gitlab branch you get feedback in 3-5 minutes that you didn’t break any tests and you didn’t break any builds on all supported platforms. This allows the team to move completely to a model where every single commit goes through gitlab merge request and code review. It provides confidence that builds are not broken. It moves the bar of code quality higher.

This is doable today with dedicated machines.

Now add to this good test coverage and you are pretty close to being able to cut a release every month if you want. This one will of course take time and dedication.

Nickoe and Adam Wolf will likely disagree. Windows and mac builds still depend on a bunch of manual work.

You are talking about a different issue here. Coordinating codebase readiness with libs and docs and translations etc. will be somewhat manual but it’s not the thing that is impeding fast release cycle. Look at 5.1.7 release, it took what, 1-2 weeks from code being tagged to release.

My issue is with the whole “declare a feature freeze and hunker down for 3 months to hunt down bugs” approach. That kills development velocity.

I completely agree on this. But choosing a bad example doesn’t necessarily take away from @halachal’s point: there are plenty of large projects that adapt rapid release cycle model and enjoy it’s benefits. Not all of them are the dumpster fire that is js ecosystem.

That’s what tests are there to prevent. Or at least, they should be there before such release cycle model is adopted.

That right there is the reason why any individual can’t solve this problem. This needs to be a push from project leadership. Of course a volunteer coming in to add a random feature doesn’t see it as good use of his time to overhaul a bunch of existing code in addition to implementing a feature he cares about just to be able to write a unit test for his feature. So the problem perpetuates and nobody writes tests.

In every software projects life when it gets large enough it becomes a lot more time efficient to write tests than to not write them. KiCad is waay past that point in my opinion.

I touched on this earlier and it’s good to realize that you see the same problem as I. But I think your solution is not the best, you need to separate GUI from business logic first and then you can have a lot of ROI from simple non-gui unit tests.

=======

I apologize if this post reads like a rant of an entitled user who only demands things without taking into account the volunteer nature of the project and limitations of time and resources available for development.
It’s just that I like KiCad, I have invested a good chunk of my own time into it and my plugin for it and I would like to see the project succeed and grow further.

At the same time I look at it as a professional software engineer and can’t help but compare it to the process I am used to at my workplace and it’s just… painful. Kicad development is missing on so much quality of life things that would save you the precious volunteer time and raise their efficiency. But there just isn’t enough movement in that direction.

But I should also praise the movement that does happen. Switch to gitlab was a great step and I know a lot of work went into it.
Now it’s time to utilize the platform fully.

3 Likes
20

Also to add: I’m actually happy with Wayne’s answer that the team will attempt to move to yearly releases. That’s already much better than what we have now.

21

Don’t get me wrong, I want kicad to improve too. But your professional software engineer viewpoint is what “pollutes” the view. KiCad doesn’t have an entire staff of paid full-time engineers. The amount of manpower available makes a huge difference in what can be achieved and at what speeds. It also twists what you can “force” on contributors. If you start demanding they write tests instead of features, they may just disappear altogether and you are still stuck in the same position. On the other hand, at a company, you can mandate tests and they either get a paycheck or they don’t :wink:

And what really distorts views more is many large open source projects these days are falsely “grass roots” and instead depend very heavily on some company staffing the project with full-time engineers otherwise the project would just die out from their own size.

I am staring at gui tests btw, wxWidgets has the framework for UI action simulation for testing and it looks quite easily doable.

22

I see your point and it is a sad state of affairs if kicad doesn’t have enough developers that understand importance of writing tests and would rather abandon the project than lay some groundwork for the future benefit. But I don’t think this is the case, a lot of refactoring and other work not directly related to new features is being done all the time. There just needs to be a will to extend such thinking to writing tests: this is necessary work that will more than recoup the time investment in the years to come.

23

Honestly, I don’t really want to engage with this thread anymore that much because of the attitude that the KiCad development team doesn’t know what they are doing, are out of touch with how software should be developed, and so on. But I will make one last try at explaining why the situation is not as simple as you would like it to be.

KiCad developers are not “anti-test”. We are not against decoupling core logic from the UI, either. We are not against CI getting better.

What we are is product-focused. We will not stop developing the product in order to make some global rewrite of the entire codebase to decouple GUI from logic, for the same reasons that we will not stop developing the product in order to rewrite the GUI in Qt or something like that.

But I think your solution is not the best, you need to separate GUI from business logic first and then you can have a lot of ROI from simple non-gui unit tests.

You seem to think that if we just wanted to, we could separate the GUI from business logic overnight, and then everything would be good.

The fact is, we are separating the GUI from the business logic. But, this process will take years, because we are doing it gradually, in small areas at a time. KiCad has a very long legacy, and we cannot blow up that legacy and start from scratch, nor will we decide that it makes sense to focus the majority of our efforts on such refactoring.

I could point out the big steps forward in decoupling and test coverage that happened between V5 and now, but I think this post is getting long.

If you are reading this, are a skilled C++ developer, and think that the KiCad team is doing things wrong, maybe consider offering to help (on the developer’s mailing list, not here) rather than just ranting and imagining that we are choosing to do things wrong because we don’t know any better.

9 Likes
24

I’m not much of a programmer myself, though I’ve been tinkering a bit with C and C++ for uC’s for some 30 odd years, and have wetted some of my toes in a bit of Python.

Most of it was from before the Internet, and even if “Test driven development” and “Unit testing” was already invented back then I did not know about it.

I did read up on it, and quite liked it though. Had a few experiments with Python.
Somewhere halfway a progam, you find a bug, and have some trouble in locating it.
Then, when the bug is located, the first thing I did is write a litttle snippet to reproduce the bug easily and quickly. Then fix the code, so the bug is fixed. However, the “little snippet” I wrote to easily reproduce the bug is also a unit test. You can remove it, or save them all up to get a big collection of these tests and add a few text strings to spit out to a terminal (or a file).

Once I found out this way of programming and debugging I quite liked it.

Writing those tests afterwards though would be very difficult to do. Writing them simultaneously with the code however was fun (for me) and useful too.

But you probably know all this…

25

I never implied that you don’t know any better, nor I imagine that things can change overnight, nor I ask to stop all development and put all effort into refactoring and writing tests.

If this is what you took away from my post then I failed completely at bringing my point across.

To avoid further frustration in this thread I’m not going to continue this discussion either.

26

My 50 cents as well :wink:

I’m a software engineer and I follow the KiCad development since at least 5 years now. From my point of view, the KiCad team is quite professional, and all the problems like modularization, etc. are quite known. In fact, I would call KiCad a continous refactoring project, because thats simply what is happening in the background besides new features (and quite a few features originated due to refactoring of core systems like connectivity).

It’s easy to say the devs need to do x,y,z, but that does not help anyone. The devs are very aware of all the underlying issues in the codebase, and there is continous work to improve things (like removing the inch/mils hack, which you only know of when you actually read the source-code, as fixed a few days ago). If you know how to code C++, please contribute. Not all refactoring requires deep understanding of the codebase. I will try to help as well with refactoring during the feature freeze.

4 Likes
27

Although I’m a developer, I can’t understand C/C++ to save my life, so let’s put this apart for now, let’s talk about the releases :sweat_smile:

I think it’s important to remember that Kicad has a very specific userbase, and a very specialized one. Kicad is used to create real things, and real things can cost a lot of money, so any error can be a huge loss for the users!

Based on this fact, what about implementing a Long Term Support structure?

The LTS is a specific release planned to be stable for a long time, while other releases are focused on bringing the latest features to the public.

This way we can release a Kicad 6.0 LTS, for example, that will be the stabe version for the next two years. It’ll have support and bugfixes until the next LTS version.

Them we release Kicad 7.0, with a new feature. 7.0.1 fixing those bugs, 7.1 with another new feature, 7.1.1 withouy features but with bugfixes, 7.1.2 with more bugfixes, and so on… Those releases are planned to be “short lived”, and has only support for the last 2 releases, for example.

And a lot of releases later, when we are on kicat 7.14.3 or something, we get this current version, apply all the latests bugfixes and release it as Kicad 8.0 LTS. This version replaces Kicad 6 and has all the features released on Kicad 7.x.y version, with the bonus of being used and tested and modified by the users for a long time.

This way we can keep a stable version for companies and big projects and we can have a still-stable-but-can-brake-sometimes version for hobbists or small projects.

What do you guys think? Is it doable within the current dev workflow? :slight_smile:

28

Companies that need long-term stable support for older KiCad versions already have the option of paying for that support. This funds some of my work as well as Wayne’s.

3 Likes
29

It would change the workflow by definition.

At the moment the stable and the development branches diverge more and more when development goes on. Fixes for the development version aren’t always applicable to the stable version or vice versa. Fixing even a bug which appears to be similar may require completely different code. It doesn’t make much sense to keep the developers keeping familiarity with two codebases and fixing bugs which affects only a small percentage of users.

It would be interesting to know how many projects of size of KiCad use a LTS style release policy. I don’t think there are many. It’s different for operating systems which actually must be kept very stable for many purposes for as long as possible. End user products, especially GUI programs which create documents, aren’t nearly as critical. KiCad is focused and narrow and within each company, even big ones, the effects of updates and other changes are much smaller than that of the operating system.

Add to that what Seth said, and I don’t think it makes sense to support several versions with non-paid workforce.

But I would really like to see smaller bug ratio in the development version. The chance to get new testers will lessen with every bug. However, I understand the difficulties of possible solutions which have been discussed above.

1 Like
30

I do not see much benefit for a LTS version.
KiCad is not like an operating system (even that installs in 10 minutes these days), but installing and configuring all prorams you want to use for that operating system can take a lot of time.

KiCad is “just a program”. As a hobbyist, I’m quite fine with installing newer versions as soon as they are officially released, I’m even thinking about putting some toes into 5.99.
As a company I may be a bit more cautious, maybe wait a month or two before an upgrade. But even so. If there is a serious bug. It’s pretty easy to uninstall and revert to an older version if needed. As long as the mayor version number is the same, there will be no file format changes, and that should be enough.

I am curious for reasons for companies to pay for support for KiCad V4, as it costs more then support for KiCad V5, has less features, and upgrade is free and I’m not aware of mayor bugs in KiCad V5.

That said, back to the original question.
In the completely unofficial guesstimate below, there are 8 months from “Feature Freeze” to “Release” for KiCad V5.

And the guess was quite accurate, with release on:

Overall I’m quite happy with the way things are progressing.

1 Like
32

One good thing about defined release cycle would be to set certain achievable goals for each release.
However for the product used for “serious work” (and probably KiCad users do use it for serious work), it’s important to have an usable version despite new features.
5.1 seems so mature now, that it can be considered “production ready” and still receives patches with new builds. That’s great.
6.x on the other hand is far from “well defined”, and in many aspects, will probably need wide user base to find all the regressions introduced after 5.x.
To me Libreoffice is kind of product that kills functionality by fixed release cycle. I’ve just tried 7.0.2 and immediately found few “show stopping” bugs; and that’s my prior experience with the LO project, where I was biten by new show-stopping bugs in theoretically tested and field-proven piece of software.
One potential problem of the 6.x, that will make it hard to adpot for “serious work” is the file format incompatibility. If I find some issue on the 6.x, there’s no easy way back to 5.x line; and show stopping bugs in 6.x are almost cerain (as with all complex software project).

33

I haven’t found this to be true. Maybe I’m not using the new features yet, but it’s pretty easy to edit v6 files back to v5.

34

An important issue with V6 is that it cannot save as a V5.1 compatible project.
Software like LO can still save as “.doc” with loss of features, but readable.

35

Yes KiCad itself is free, however any update has a cost.

For a start you need to retrain your employees as KiCad does change quite a bit between versions (This cost is low compared to what you gain so you will most likely chose to do it).
However, you also need to somehow transfer your old projects to the new version which again takes time and effort. It is also a nightmare for accountability as you can now no longer state that a project transferred to the new version has been untouched.

And we haven’t even mentioned the IT department here.

36

Document processors create files that are supposed to be opened by a large variety of software: older versions of LibreOffice, sure, but also Microsoft Word, Google Docs, and many others. So, creators of document processors need to put special effort into ensuring this kind of compatibility. You could kind of think of the Microsoft “.doc” and “.docx” formats as “de facto standards” that even LibreOffice has to follow if they are to get any usage, because people will need to share their documents with Microsoft Office users.

KiCad (and many other programs, to be clear) is different: there is not really much demand to share files created by KiCad with other EDA tools. We could spend a lot of effort making sure that files written by KiCad N could be opened by KiCad N-1 or N-2, but in my opinion that effort would be a waste of time. We’d rather spend that time on eliminating “show-stopping bugs” in the current release.

37

And that’s the Catch-22. Without massive user adoption it will be hard to properly debug the software; and without easy “backup plan” (roll back to known working version) it will be hard to encourage users to get onto the new version and bring valuable feedback. @halachal I know you can now do some edits to open the files in the older revision, but there’s no guarantee it will stay the same with released version. There’s good reason to use new file format.

38

Schematic and symbols?

39

The main snag with a frequent release cadence and maybe a LTS as well will be users on different versions confusing us and each other on this forum. Currently when a user posts here that they are on 4.x or 5.0.y the first thing that we say is upgrade to current release.

1 Like