TeamNewPipe / TeamNewPipe/web-api

Information for download section

Open
#1 10 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Python
Stars
36
Forks
12
Avg merge
12h 29m
Merged PRs (30d)
6

Description

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?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the proposed F-Droid metadata source, the changelogs directory, and the _data location mentioned in the issue. Establish which implementation approach is accepted and how the stable and beta API paths should expose version and changelog data. Done should include an agreed design and working release data for both channels, but the issue does not define the final scope.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, jekyll, python, shell
Domain
api, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.