Thanks for the detail reply.
(your detailed responses are an fantastic part of the Bela 'experience')
Internet - yeah, I understand your point - though perhaps quite a few of us have connections - but for sure its just a 'simplicity thing'
more important i think is clear information about versions / updates availability - its no really issue doing it as a 2 step process - download/apply.
image verses update ("bela software update")...
ok, I think the thing here is what warrants a new image?
3.6 installs hvcc, but could that not have been done as an update? (in the same way as the update can install Csound/SC?)
if I look to Organelle/Norns, basically an image is never usually required, you can simply do an update.. this will do things like run scripts to install packages, update configuration etc.
really the only requirement for a new image, is if there is really big change, e.g. a new distro, or its its just a daunting task to do as an update (e.g. perhaps installing new kernel etc)
(I think we all recognise installing an image is best avoided, its a pain on salt and some bbb, and also means you have to redo any customisations - hostname changes, wifi setup, installing your dev tools/projects)
however I will say, I think that this is already your intention too,
as I see with the image release notes, I guess many of these changes were 'big' e.g. driver changes , so perhaps the install hvcc is the 'exception' rather than the rule.
git repo vs update
ok, I think the underlying thing here, is that an 'update' by whatever method, should preferably lead to the same state on the bela board.
so i think the update release, should be a clone (depth 1) of the repo, so then on the boards its a valid repo, which you can do git pull on.
so I think the update image could be basically:
- a cloned repo (depth 1 ) , and when pulled a file is created with either a version tag, or commit tag
an update script (which copies things into the right place, installs packages etc)
( i think this is what make install is kind of doing?)
the repo should contain resources (e.g packages) it needs
( I think this is whats in resources/stretch/deb)
the idea then is updating then is:
- you can see version number of update and image on Web UI
- its clear from wiki? releases notes? GitHub? what the latest version is of update and image, so we know if to update or not.
then we can update by one of two means
- we can either download release package and apply from Web
- git pull, and then run update.sh
either way should lead to the same thing/image...
(so those of us with an internet connection on bela, can do the second and 'know' the board is updated in the same way as if we ran the release package update)
I think much of what Ive detailed about is pretty much what your doing already,
perhaps some of it is just my lack of understanding or some minor inconsistencies which make it confusing for those of use not following the 'back story'
... and I think pretty much the same/similar to what you proposed in your reply.