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
