On Fri, Jan 31, 2025 at 3:15 PM raiden00pl <raiden0...@gmail.com> 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. We could make it one of the project's conventions that every time a breaking change is merged, the commit that makes the breaking change must also add documentation about it: * What changed and why * What changes our users must make when they update from older NuttX. Where should this documentation be? I recommend a new file: Documentation/ReleaseNotes/NuttX-Next. When the release branch is cut, this file is renamed to NuttX-X.Y.Z (e.g., NuttX-14.0.0). In that file, there should be a section for Breaking Changes. Then, when someone needs to update to a newer NuttX, all they have to do is go through the release notes and make the listed changes. Nathan
