Previously we were basically on a rolling release model, that any time we making a change new images will be created for everything the build tool supports. As we added more products to the build tool the number of the images per release was getting out of hand, and it was not obvious which image is needed. We had a few forum posts about not booting, that turned out to be mismatching system image.
We then split the huge list of images into several product specific release repositories on GitHub. This way the user coming from our Wiki’s Download page, they will only be given valid choices that all could boot (as long as we don’t mess up…). We also limit the image generate frequency in those repositories to once per month. This way we reduced the support variants from tens of different images to a handful, so we can better support known issues and provide workarounds. We can also demote broken builds by marking them as pre-release, so GitHub will use a older but working build as the latest release, and that is what we present on the Download page.
In both models, we haven’t talked about testing, because it was basically non-existent back then. We had no dedicated testing team and the engineers had to do the testing. Testing takes a lot of time especially if you want to detect regression, which obviously didn’t happen when engineers had a lot of other stuffs to work on. The 2nd model was meant to take advantage of community feedback to improve the user experience, without draining a lot of time from engineers.
Now when we launched ROCK 4 SE, things have changed considerably:
- We now have a dedicated testing team.
- We are working with OKdo, who ended the license agreement with Raspberry Pi after 10 years.
OKdo saw what Raspberry Pi Foundation has done so far, and they are asking for the same thing from us. That means formal release with release note and proper testing. This puts an end to our (semi-)rolling release model. We can still use the existing facility to generate builds, but they are only release candidates now. They become a real release after testing along with the release note, and then we will list this specific version on the Wiki page.
So back to your questions:
Use 4 SE image for your 4 SE.
This or using 4B image as suggested in the last question has the same issue: it makes support more difficult, that there are more software variants we need to acknowledge. Also, while they are supposedly compatible softwares, the exact combinations were not tested by us. With a formal release procedure and quality assurance, we cannot recommend those use cases.
This is something I worked on before. The existing image builder has a lot of limitations, so I made a new one, and better first-boot setup is one of the features of the new system. It was on the back burner for a while and now we are seriously trying to get this released, so this will be something you could use in the future.
But for now there is no easy way. The closest thing is probably mounting the image and adding the Wi-Fi connection file.