Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Information for download section #1

Open
TobiGr opened this issue Mar 5, 2018 · 10 comments
Open

Information for download section #1

TobiGr opened this issue Mar 5, 2018 · 10 comments
Labels
enhancement New feature or request

Comments

@TobiGr
Copy link
Member

TobiGr commented Mar 5, 2018

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 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.

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?

@TheAssassin
Copy link
Member

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.

@TobiGr
Copy link
Member Author

TobiGr commented Mar 6, 2018

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.

@TobiGr
Copy link
Member Author

TobiGr commented Mar 11, 2018

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.

@TheAssassin
Copy link
Member

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.

@TheAssassin TheAssassin added the enhancement New feature or request label Mar 11, 2018
@TheAssassin
Copy link
Member

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.

@TheAssassin
Copy link
Member

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
    }
}

@TobiGr
Copy link
Member Author

TobiGr commented Mar 11, 2018

Thanks!

@TobiGr
Copy link
Member Author

TobiGr commented Mar 13, 2018

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
Copy link
Member

@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.

@TobiGr
Copy link
Member Author

TobiGr commented Mar 13, 2018

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants