> That is not excuse. Maintaining old API is not hard. Usually it's just a simple call to new API, which will not require further maintenence. You can even kick it to separate file so it does not break code aesthetics ;)
If it were that simple it wouldn't be a problem. But no, it isn't. I just give you 2 examples that are currently a problem, and legacy compatibility is just waste of everybody time: 1. NuttX initialization: https://github.com/apache/nuttx/issues/11321 It's not possible to solve this problem without removing and completely cutting off from the old API. Keeping the old API will continue to cause confusion for users and will not simplify anything. The only solution is to get rid of unnecessary code. Yes, it will break users' applications, but the fix on user side will be simple: remove calls to the unsupported API and choose the arch-specific initialization method that interests us (in most cases this will be done automatically). 2. PWM refactorization: https://github.com/apache/nuttx/issues/12381 Keeping legacy versions means increasing the number of #ifdefs in low-level implementations, which is something that this problem is trying to solve. In the end we end up with more complicated code, which means the effect is the opposite of what was intended. Another option is to keep the legacy implementation in separate files as you mentioned, in this case we end up with more than 20 extra files and probably an additional set of Kconfig options. The effect is again completely opposite to what was intended. On the other hand, the change on the user side will be trivial This: pwm.duty = 0xdead; pwm.frequency = 0xbeef; changed to this: pwm[0].duty = 0xdead; pwm[0].frequency = 0xbeef; Do you see the difference in scale here? Two broken lines for users vs. hundreds of lines of meaningless code. The cost to the user is basically nothing, the cost of a bad API and the resulting consequences is high. Another case is the CONFIG_PWM_PULSECOUNT problem. This feature shouldn't even be part of the PWM driver. It's a completely different functionality that deserves a separate driver and API. Again, keeping legacy compatibility here doesn't improve anything, it just complicates things even more. Are these APIs part of some standard? Are they marked as stable anywhere? No, they are not. So expecting them to be stable forever is pointless. Especially in such a dynamically changing and complex environment as embedded systems. No one here is talking about change for the sake of change. I'm talking about fixing things that are broken from the start. Keeping bad code to make ALL users happy is, in my opinion, a great example of "bad engineering" or at least "people pleaser" syndrome. But I understand that we can disagree here :) pt., 31 sty 2025 o 23:43 Tomek CEDRO <to...@cedro.info> napisał(a): > On Fri, Jan 31, 2025 at 10:09 PM <michal.lyszc...@bofc.pl> wrote: > > > > On 2025-01-31 21:14:23, raiden00pl wrote: > > > > No, just be super careful designing API to "userspace" and once > commited > > > it > > > stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as > > > well. > > > That's why we still have "creat" instead of "create". Or we have 3 poll > > > APIs in > > > Linux (select/poll/epoll). You really want to change API, you build > another > > > one, > > > and mark old one as deprecated, but you don't delete it. That would be > ok if > > > Nuttx was <1.0.0, version, but it's >=1.0.0 so it should care about > API/ABI. > > > Especially that it does not have to come up with API and just use what > Posix > > > been using for decades now. > > > > > > I can't agree with this. Stockpiling legacy code degrades code > quality, the > > > code > > > is harder to maintain and is harder to use by users. > > > I think there are cases where it's justified to break compatibility. > > > Especially if > > > the breaking changes for the users are easy to fix and detect, and the > > > interface > > > that is being modified has obvious flaws. And of course, everything > should > > > be well documented. > > That is not excuse. Maintaining old API is not hard. Usually it's just a > simple > > call to new API, which will not require further maintenence. You can > even kick > > it to separate file so it does not break code aesthetics ;) > > Guys this discussion takes time and gets more and more theoretical. > > Please provide examples where applications were broken, how, and we > put remarks in contributing guidelines to avoid that. In the best case > I would also see fix proposition on GitHub if you need that fixed. > > I guess the problematic part is the build process and/or CONFIGURE > change and this comes from RTOS. The rest is POSIX and should not > change. > > ESP IDF tells that Kconfig has this option to mainain backward > compatibility. That would create maintenance mess, but in theory it > should work: > > > https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/kconfig/component-configuration-guide.html#how-to-ensure-backward-compatibility > > > For me the problem is a bit invented because nuttx and nuttx-apps are > not in sync. Documentation clearly states to use repo clones or > release packages pairs. Yes we want to be as self-compatible as > possible, but no one mentions backward / forward compatibility. The > solution is just to keep nuttx and nuttx-apps repos in sync. > > > > Inside nuttx repo you can break all the APIs you want. But outside of it > this > > should not happen. > > Except apps repo is built by nuttx repo and here is the problem I guess? > > > > Take expamles from other projects. I can update my openbsd with 0 > issues. And if > > some breaking changes in configs are introduced you always get great > > documentation what has changed and how to prepare for that change. > > I prefer BSD too for that reason, but OpenSSL also changes API > frequently, kernel API changes happens in BSD too. > > > > Creating something new is always fun and is easy. But you have to > maintain it > > later thru the updates. There is a reason why I am not getting even > close to > > ruby. I'd rather use clunky PHP which has some problems on its own, but > it never > > broke my software/installation with updates, while with ruby based apps > there > > was always struggle. > > Until you have PHP3 application and all servers on the planet updates > to PHP7 and then your application can go to trash. Happened to me many > times :-) > > Other RTOS will change stuff on a weekly or monthly basis. If this > happens here its a bug not a feature. Problems happens we need to fix > them :-) > > > > Change just for the sake of change never worked out well for anyone. > > No one thinks that way here to enforce changes, we usually resist them :-) > > Have a good weekend folks :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
