Hello everyone, While making changes to some of the documentation here on NuttX, I noticed that some of the very old NuttX releases actually had release notes included.
I took a look at the NuttX GitHub page, and now it seems that version updates (for instance, 12.9.0 recently) are created as "tags" on GitHub (listed here https://github.com/apache/nuttx/tags), as opposed to "releases" (here there are none https://github.com/apache/nuttx/releases). Some of the other open source projects I follow make use of the release feature on GitHub, which actually makes the release visible on GitHub's explore page and also has additions like a "latest" tag, etc. Here's one by FreeCAD: https://github.com/FreeCAD/FreeCAD/releases/tag/1.0.1 Another great thing to add would be to bring back release notes. I am fairly certain this can be automated using CI tools, which track which issues were closed and can also add notes based on the commit messages (i.e. sort by the topic that is enforced in front of each commit message). This was one of the first ones I found: https://github.com/marketplace/actions/release-notes-generator I think bringing back the release notes might help NuttX users see the progress being made towards NuttX become more stable (and also supporting many more features). They'll be able to see all the bugs that contributors fix with each release and also see all the new features highlighted. This is much nicer than having to check on issues on the GitHub page, and it might also help users to discover some new capabilities that NuttX has. One final idea: some of the releases that projects on GitHub make are nightly releases (such as this one by FreeCAD https://github.com/FreeCAD/FreeCAD/releases/tag/weekly-2025.05.19), and they're marked as "pre-releases". Those releases have different content in their descriptions, like the process to build and launch the application. I think NuttX could leverage this for the RC releases during voting periods by having pre-releases that automatically include all of the instructions for testing the release candidate and issuing a vote for or against it. This might help involve more users in RC testing, even if they weren't originally part of the mailing list. Of course they will still have to vote on the mailing list, but this is another location where they can be exposed to the RC and read about the testing procedure instead of having to find it themselves in the docs. Is there any interest in setting up some of these release options on our GitHub? I can maybe look into it further, starting with generating release notes automatically from commit history. -- Matteo Golin
signature.asc
Description: PGP signature
