Recommended procedure to rename apps

Hi,

I have a technical question regarding apps whose name change over the course of their life, or where the community transitions to a fork.

We have a current case with the ZeroBin app (official): It’s been migrated from the original ZeroBin app to the PrivateBin fork. The PrivateBin fork has been designed to stay backward compatible with ZeroBin.

So now we have a YunoHost ZeroBin package, which name is Zerobin (name field in the manifest), and id is zerobin.
What’s the best procedure to handle a smooth upgrade of current Zerobin instances?

Right now there’s a PR to just upgrade ZeroBin YunoHost package to install latest PrivateBin version. That should make the deal, but we’re still advertising ZeroBin as our official app…

Is there an existing or planned system to rename apps id and still keep track of which app needs to be upgraded?

Otherwise, what would be the best behavior here:

  • keep ZeroBin name everywhere (except in the README) as in the PR
  • change ZeroBin package name to PrivateBin, and keep the “zerobin” id
  • create a new PasteBin app, and remove ZeroBin app from official repository (and move it to the community repository…?). But then, how to have users make the switch to PrivateBin (exept writing about it here on the forum and on the official doc)?

Any information/suggestion will help :slight_smile:

The case already happened in the past with owncloud/nextcloud, and the nextcloud app is able to manage an upgrade from a owncloud instance : https://github.com/YunoHost-Apps/nextcloud_ynh#migrate-from-owncloud

But this is not easy and integrated, more like a smart hack. I guess Yunohost does not support this yet.

We could rename the app on the manifest and on the app list.
People won’t get update for their current ZeroBin instance.
The update will need to be done manually to get PrivateBin.

Sorry for French ™

Yesterday discussion on it:

00:05 @<Bram> jimmy: c'est compliqué ™
00:06 @<Bram> les seuls cas jusqu'à présent ça a été de faire une autre app et de permettre aux gens de migrer en CLI
00:06 @<Bram> ce qui est très insatisfaisant car tu laisses énormément de monde sur le carreau
00:06 @<Bram> une idée que j'avais eu c'était de permettre, dans le manifest d'installation de l'app de mettre une autre 
              app depuis laquelle migrer
00:06 @<Bram> mais ça n'a jamais été fait
00:07 @<Bram> (mettre l'id d'une app déjà installée)
00:07 @<Bram> c'est un mécanisme qui serait aussi nécessaire pour des apps comme agendav ceci dit
00:08  <maniack> Ça me semble faisable ça
00:08  <maniack> Sans changer quoi que soit
00:08 @<Bram> oui, c'est déjà faisable
00:08  <maniack> En ajoutant une option au manifest et prenant en compte ce paramètre lors de l'install
00:08 @<Bram> là j'avais en tête des facilités comme des nouveaux types d'arguments dans le manifest
00:09 @<Bram> genre "installed_app"
00:09  <maniack> Je pense qu'on pourrais déjà le faire à la main, pour débroussailler
00:09 @<Bram> ça serait idéal oui, voir même de faire ça pour nextcloud <- owncloud rétroactivement
00:10  <maniack> Oui, c'est toujours d'actualité
00:10  <maniack> Il y a encore des migrations
00:10 @<Bram> ma brique par exemple
00:10 @<Bram> :p
00:11  <maniack> Juste par contre, ça oblige à indiquer manuellement l'id de l'app
00:11  <maniack> Ou le path à la limite
00:11 @<Bram> 00:08 @<Bram> là j'avais en tête des facilités comme des nouveaux types d'arguments dans le manifest
00:11 @<Bram> 00:09 @<Bram> genre "installed_app"
00:11 @<Bram> oui
00:11  <maniack> Oui mais ça implique une modif du core
00:11  <maniack> Mais oui ce serait idéal
00:11 @<Bram> (et de l'admin web)