Thank you for your suggestion. Unfortunately maintain builds across multiple SBC versions, x64, OEM requires more granular approach (already implemented).
Under normal circumstances, there is no need for community users to navigate across builds or releases. Occasionality, there will be exceptions, discussed in our community forum.
this is impossible, because the images are created, then they are tested with internal QA procedure, and then released as stable if they pass all the test.
the changelog date is the day when they are promoted as stable.
the filename is generated automatically by the build process, and the date in the filename is the build date
how about adding the stable release date into the change log as well, that would be useful information and makes it alot easier for people who want to try a particular release
Or simply the complete filename of that particular release.
the changelog is for all devices and platforms, not only for RPi
the images for different platforms might have been built on different days, that’s why we set as release date on the changelog the day when it’s promoted as stable
Just going by the main website there are only 2 official platforms
Was just a suggestion to make the change log relate to the actual release name so people can easily download the version they are after.
You can stitll get the version you want, you just have to laboriously type in descening dates till you hit the right one.
If this is not much to ask - can you be a bit more specific and describe in details what is that makes you move backwards?
Technology as such, moves forward and with new Pi SBCs emerging (Pi 5, 500, CM5), DSI screens, DACs, we simply can not remain unmoved, taking that there are no plans of backporting “new” to the “old” from all upstream sources. On this note, we need technical details of your builds to understand and address hiccups (if any).