Another problem with changing the file formats every year is that it breaks a random portion of the 3rd-party utilities that support KiCad. Each new KiCad release scrapes off a portion of the ecosystem that supports it. This is fine if the KiCad development team understands that eventually all features will have to be developed and supported by them, but it seems a shame to waste the efforts of the community.
The team wants to eventually have a stable API for third-party tools to interact with (we’re slowly making progress towards that). I don’t think we will ever treat the file format as an API contract; we’d rather have third party software interacting with an API than directly editing KiCad files. Freezing the file format in order to make the lives of third party developers easier would unfortunately not be practical at this point in time.
it’s only in the picture in life, not everything is so smooth … similarly with the transfer of projects from version to version
KiCad has backwards compatibility. Newer versions will open older files.
In fact, I’m still using my libraries I authored in KiCad 4.0. I’ve only migrated those I wanted to edit.
when transferring a project, new errors appear that were not in previous versions, for example, between versions 6 and 7, when transferring, more precisely, converting libraries, the connection is lost and everything has to be done by hand … these are known problems, they can be solved, but this is not pressing one button … requires a lot of effort
As volunteers, the KiCad dev team can do as it wishes.
But, the constant refrain I hear on this forum is “There is only so much they can do within the limited free-time of a small number of developers!” If that’s the feeling of the dev team, then maybe they should put more emphasis on 3rd-party developers who can fill in the gaps in KiCad. For example, kifield was developed years before the more-limited bulk-editing of schematics appeared.
Plus, 3rd-party devs are some of the most enthusiastic promulgators of KiCad. They have to be if they’re willing to put hours into building these tools! If the attitude is “we’re not going to make life easy for you”, then they’ll find other things to do. I guess KiCad can exist without an ecosystem, but a monoculture isn’t very resilient without a lot of extra work for the main devs.
1 Like
I don’t disagree with your general premise, but if you are implying that we should freeze the file format so that third-party developers who specifically write stuff that manipulates files directly don’t have to change things every major version, that is not currently a good idea for the long-term health of KiCad.
One of the way third-party devs can help is by understanding why the KiCad process is the way it is, and committing to supporting their tools by building them in a way that can handle the yearly file format changes with minimal effort. Eventually this won’t be necessary as a real API will be available, but for now, developers who understand that KiCad’s file formats have to continue evolving and changing and write their code to accommodate this will be more successful than those who are upset that the file format is not fixed in stone.
explain what constant api means and when will the annual change of formats end?
Right now, KiCad has no API. What this means is that there is no way for third-party developers to write tools that interact with KiCad in a stable way across versions.
The annual change of formats will not have a specific end (we aren’t going to declare one year “the file formats will not ever change anymore”) however the impact of that change on users and developers will go down. Once an API exists, developers can re-write their tools to use the API instead of directly reading KiCad files, which means they will no longer care about annual changes in formats. Once there are no longer outstanding major feature requests that require significant changes to the file formats, the annual changes will become smaller and more isolated in scope. At that point, it becomes more realistic to consider things like making it possible to open newer files in older KiCad, and things like that.
1 Like
There is a middle-ground between “fixed in stone” and “having the consistency of an ideal gas”.
One simple thing that would fix some of the problems (but not all) would be to add an (extra ...) clause to elements in the S-expression files. That would give the main devs a place to add all their cool ideas, but 3rd-party devs could skip over them and access/modify the more stable stuff. Every few years, the main devs could migrate stuff out of the (extra ...) clause as it becomes stable. That would also serve to trigger an update on the file format docs (which are still out-of-date w.r.t. KiCad 7).
Building such an idea would be complex and take time, and we have decided that now is not the time for that. We’re instead investing time into the changes required to provide a real API. Something like you propose may be investigated later, though. For now, we do not want to lock in the current state of the file formats and put only new things in “extra” – we also want to continue refactoring and fixing problems in the existing file formats.
For example, see this issue: DRAFT: S-Expression normalization (#15232) · Issues · KiCad / KiCad Source Code / kicad · GitLab while we won’t be doing all of those things, we’re certainly looking at doing some of them. There is still a lot of change needed to the existing file formats (not talking about adding new features) before we would be comfortable calling them “done”.
1 Like
there are no specific dates for endless change, right, I understand? how do you determine the end of core feature development? is this version 9 or 10? or year two three five? it looks like doing it in order to do it and not to get a good product for users … I don’t know more than one cad that changes formats both paid and free every year
When professional users are no longer requesting that KiCad do new things that are only possible with file format changes
3 Likes
I’ve heard about new and improved KiCad APIs for years, so I’ll leave this conversation with the words of a wise philosopher:
2 Likes
for example, version 6 of the last one was thrown with errors and their further elimination did not occur, although there were no new functions there …
I am not sure I understand you – there were many many new features in version 6.
@devbisme I hope your attitude improves eventually.
Do you understand that this is not real? requests will always be tomorrow they will want to have a gerber editor in a year to draw drawings in kikad and in another month to edit 3d, while the declared functions do not work so correctly … without planning, this is an eternal change of formats and instability … version 6.11 had many features but it was abandoned and there was a change of formats … those errors that were there remained there throughout the entire 6th branch …
6.0 is not abandoned, it is just no longer actively developed by volunteers. Bugfixes for 6.0 are available by paid contract. Many people still use 6.0. At this point it seems to me like you are just complaining for the sake of complaining, which you seem to do in many threads on this forum.
you perceive criticism as a complaint or an insult … maybe I’m wrong and changing formats every year is a normal practice, but I have not seen such systems, both paid and free … if we talk about paid support for version 6, then this is at least not the best investment … now I understand more why the developers do not want to switch from altium completely … and this is confirmed by the survey …
Are these fixes offered to everyone as open source?
I am anchored to v6 for professional pcbs (my own decision) because is stable enough. I use v7 for experiments though I think I will move to v7.99 so I can help in testing.