Open TobiGr opened 6 years ago
Since this is dynamic data, it can't go into the website repository without having a service or cron job make a commit whenever data changes. Therefore, we should do it here in the API.
If you design a JSON format containing the data you need, I can code the necessary parts in the API required to fetch and convert the upstream data.
I'd suggest something like this. If you have any alternative, please tell me.
api {
"stable": {
"version": "1.0.0",
"changelog": "something HTML escaped"
},
"beta": {
"version": "1.0.0beta",
"changelog": "something_"
},
"githubStats": {
"stars": 3030,
"contributors": 180,
"commits": 1800,
"languages": 43 /* WebLate */
}
}
If necessary, we could prefix or group the stable
and beta
with app
. This might me helpful when the Android TV version is available. But I guess TeamNewPipe/NewPipe#939 needs some more time until this separate APK gets released.
Can you also provide the data in JS format like this:
var api = {
"stable": ...
...
};
It would be extremely helpful for me because I could include it much easier in the website.
And contributors
, commits
and languages
are not that important. When you do not have time to get this data, it is not a problem for now.
Your first example isn't valid JSON anyway.
I suggest something slightly more generic:
{
"flavors": {
"stable": {...},
"beta": {...},
},
"stats": {
"github": {...}
}
}
I'd work out the final layout while writing the API, if that's okay for you.
I rewrote the HTTP fetching code to make all requests in parallel, the API runs in about the same time as before. It fetches the stargazers count from GitHub, stable and beta versions, etc., and assembles a single JSON object containing all the information:
{
"flavors": {
"beta": {
"version": "v0.12.0-beta"
},
"stable": {
"version": "v0.11.6"
}
},
"stats": {
"stargazers": 3051
}
}
We can easily extend this, with further requests, or other data from the ones already performed.
I'll commit the current state soon. I won't deploy it until you adjusted the website's code.
Current state:
{
"flavors": {
"beta": {
"version": "v0.12.0-beta"
},
"stable": {
"version": "v0.11.6"
}
},
"stats": {
"contributors": 30,
"forks": 467,
"stargazers": 3051,
"translations": 43,
"watchers": 3051
}
}
Thanks!
With additional information from the changelogs dir (which we should use btw to tell people in the F-Droid app directly what changed), we can display some more details about the releases.
@TheAssassin 2nd paragraph of my first post :)
@theScrabi Can you please add changelogs for the next releases? I'll need that for the website and the What's New dialog in the app. See the F-Droid docs for more info. Thanks!
@TheAssassin 2nd paragraph of my first post :)
I built the API after the data model you provided. I'll work on it maybe on Thursday.
Thanks
For the new download section I suggested in TeamNewPipe/website#50 we need to gather some more information. First we need the current stable and beta release. Since we can't get the latest beta release via the GitHub API without going through all releases, my idea is to use F-Droid's release data: https://gitlab.com/fdroid/fdroiddata/raw/master/metadata/org.schabi.newpipe.txt. One big advantage is that we'd only promote new releases which are already available on F-Droid. I think that's necessary since I use the download icon as link to NewPipe's F-Droid release page.
It shouldn't be that hard to find the line that contains the
current version
, the matching build / tag and version code. With additional information from thechangelogs
dir (which we should use btw to tell people in the F-Droid app directly what changed), we can display some more details about the releases.I'd suggest following structure for that:
api/[stable|beta]/current/[version/changelog]
.I don't like the idea of doing it with JS, but since we are going to need that information for the "What's New" dialog too, we should implement it in this or a similar way.
Another idea is to write a .YML file in
_data
with a shell or python script. This data could be easily used by Jekyll in the site generation process and wouldn't require JS scripts. With this data it would also be possible to provide the api for the app as long as we don't need to much information. A small disadvantage is that we'd need to re-generate the site twice a week or so.What do you think @TheAssassin. Should we try to do it with a shell script?