colin/linuxphoneapps.frama.io
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Blog post: Typo

Browse Source
This commit is contained in:
Peter 2022-03-29 13:46:00 +02:00
parent bc98afc3e4
commit 01f51d2251
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/blog/its-better-to-launch.md
View File

@ -33,7 +33,7 @@ There's no regression compared the previous state: The original JavaScript heavy
* [Games](https://linuxphoneapps.org/lists/games),
* [Archive](https://linuxphoneapps.org/lists/archive), which has been partly re-integrated into apps.csv (with the status set to archived or inactive) and now only lists two apps for which re-integration did not make any sense.
We're also not loosing any Git history, as the original .csv lists are not only meant to stay here, but their [repo](https://linmobapps.frama.io) is still intact and a part of this project. It really should be moved to be part of the same organization, but in order to make this transition easier it will remain where it is. Also, a single source of truth, such as apps.csv, has it's benefits - it can be reused in [third party](https://github.com/Speiburger/LINMOBappsBrowser) [projects](https://framagit.org/1peter10/simple-applist) easily. Yes, CSV is ugly, but as long as there's no replacement (e.g. in XML), we'll have to keep it around.
We're also not loosing any Git history, as the original .csv lists are not only meant to stay here, but their [repo](https://linmobapps.frama.io) is still intact and a part of this project. It really should be moved to be part of the same organization, but in order to make this transition easier it will remain where it is. Also, a single source of truth, such as apps.csv, has its benefits - it can be reused in [third party](https://github.com/Speiburger/LINMOBappsBrowser) [projects](https://framagit.org/1peter10/simple-applist) easily. Yes, CSV is ugly, but as long as there's no replacement (e.g. in XML), we'll have to keep it around.
Also, with all the caveats applied, this should be a lot better then what we're had before, for repology integration alone!