wtfos-configurator
wtfos-configurator copied to clipboard
fpv-wtf
Show release notes
Show package release notes for packages to be updated? If so, how would that work. We could link to the release itself, but I don't see a way to enforce anything...
Well, just rendering the markdown from the release notes should do. Maybe with x lines by default and expand to show more?
I realize this leave us somewhat at the mercy of package devs, but then again, even Apple does this on the app store.
C/P from Discord: I could imagine is an additional field in the control file where we could add some info, if present we will display it after/before updating? But this would have to be one message for the whole update addressing all packages.
Your suggestion would imply that we only do per package updates and not whole system updates, which is fine for me too, just the update mechanics would then need a complete overhaul and I currently don't see how we would solve package dependencies. EG: We update package A, but it expects package B to be at a certain version.
Guessing the configurator consumes this https://github.com/fpv-wtf/opkg-repo/blob/gh-pages/pigeon/Packages ? And I presume that is auto generated somehow by the publish process ? And I think someone said you can add extra fields to the opkg metadata without breaking anything?
If all that is true, what's to stop us putting JSON into a field, with the per version release notes in....
{
"0.6.8": "Font names changed.....",
"0.6.7": "Nothing breaks",
"0.6.5": "Bleh"
}
Configurator can parse that JSON, and then work out which messages are relevant.
Could populate it form the release notes in github? There are some here detailing the fonts change, but they don't really surface anywhere... https://github.com/fpv-wtf/msp-osd/releases/tag/v0.6.8
I'm a bit hesitant in terms of bloating the Package index with lots of additional metadata. It's meant for opkg to be able to do it's job.
An alternative could be that opkg-repository builds an additional .json file with extra metadata the configurator may care about.
Thoughts? I certainly don't also want to make this any more complicated than it needs to be.
We also have to keep in mind e.g. entware packages will never have any of our additonal meta.
We might want to re-evaluate this in the context of fonts and the configurator and preview images.
That one is at least somewhat constrained. This one, especially if we're including past release notes, will blow the f---- up...
I still need to investigate if opkg in the CLI cares about bloat in the package index (I remember seeing it using a fixed sized buffer for reading control file values, I am just not entirely sure if it cares about "custom" fields).
Additional meta meta file is also an option - we should then consider this also for the fonts.
I still don't see a good way of making the user read and understand it - especially since there might not just be a single update (and updating single packages has its own risks). What would be your suggestions for this? Show him the release notes after all updates ran through?
We might want to re-evaluate this in the context of fonts and the configurator and preview images.
That one is at least somewhat constrained. This one, especially if we're including past release notes, will blow the f---- up...
true. 1 per package probably sensible, rather than 1 big file ?
true. 1 per package probably sensible, rather than 1 big file ?
Might as well fetch the release notes from GH API at that point?
Personally I think a big bundle for configurator meta for the current state of the repo is fine. I'm far less concerned about browser JSON parser than I am about opkg getting weird/slow when the index is 90% irrelevant data.
I still don't see a good way of making the user read and understand it - especially since there might not just be a single update (and updating single packages has its own risks). What would be your suggestions for this? Show him the release notes after all updates ran through?
I could see us listing each package to be updated, along with say 5 lines (expandable for more) max or the release notes by default, on the update screen. Include both the text, as well as a link to the release if they want to open it in a new tab for later reading. Conceivably we could also leave them on screen during/after the update.
After that, it's up to the user.
If we ever add the ability to update individual packages then the same mechanism could be re-used. However with opkgs problems with versioned dependencies, I don't think we can do that now. In fact there's an argument to be made to forcing the user to update before they can install any new packages (since we don't know, if there might be a dep issue).
I could see us listing each package to be updated, along with say 5 lines (expandable for more) max or the release notes by default, on the update screen. Include both the text, as well as a link to the release if they want to open it in a new tab for later reading. Conceivably we could also leave them on screen during/after the update.
Makes sense - we are listing packages to be upgraded anyway beforehand, adding additional meta there should not be an issue (once we decide on a method how to add that meta).