App update cycle

First of all thanks for the good work the volunteers are doing here.

I’m fairly new to Yunohost - I used to set up and update the programs and apps I needed myself, but this way is much easier.

So the Yunohost system supports me very well in running my own server.

My question, I’m not familiar with the internal processes, is how often updates with the corresponding bug fixes appear for apps.

For example, I can see on Git that the Misskey App (master actually v12.102.1) updates (to v12.107.0) are being attempted, but are unsuccessful.

Should I be concerned that Misskey will no longer be supported, or just be patient?

I wish you all a nice day and a relaxing weekend.

I’m not sure that I understand your question, but if you’re asking about how often packaged apps are update:

I believe the general rule is : it depends on volunteer efforts, so it’s kind of irregular and really varying depending on the app (its easiness to be maintained, how much interest about this app) and time (number of people available to contribute, how hard is a particular update to implement)…
One way to get informed is to subscribe to each github repository, and watch the status of the Pull Requests, in particular the ones named “Testing” (which are the last changes merged to the master branch, so the version you get thanks to Yunohost update mechanism).

That may be a bit different the kind of “core” apps (the one most supported by Yunohost contributors, in particular Yunohost app team, such as Nextcloud for instance) where as a matter of fact more efforts are put into updating them, so there are quicker and more regular updates.

That is the reason for my question.

It would be a shame if I set up a public Misskey instance and then couldn’t maintain it.

Thanks for pointing out the “Testing” Git repo.

From a user perspective it would be useful to know what the core apps are. As far as I know they are not defined somewhere? The yellow star in the apps catalogue is about code quality, not about core or not? I suppose Wordpress belongs to core, but what else?

1 Like

I think “official” apps was a thing (there was a official catalogue and a community catalog IIRC), but that’s not the case anymore.
The yellow star is about app quality over time (level 7 over the last 6 month).

I agree with you.

It would also be interesting to know whether I can update apps manually, despite installed them with Yunohost.

Hi @Memo !

I’m not part of Yunohost team, so this will be only my own opinion and experience.

  • I have been running Yunohost since 5 years without any issue related to app maintenance. In my admin panel, three of my apps show an installation date in 2017 ! What works one day works the day after. I would say that the biggest “danger zone” is when Yunohost is migrating to the next Debian version, but even in that case,
    • The Yunohost team is usually very prudent
    • You will always find a testimony of some advanced user that is using the same apps as yours, and that has migrated with success
    • In extreme case it’s quite easy to come back to a pre-migration setup, raise an issue on the Github app repository and wait for that issue to be solved before migrating
  • There is no more such thing as “core” or “non-core” app. There is now an app level (code quality and safety of use) which shows an “instantaneous” level of quality, and a yellow star, which shows a good quality over time. In my opinion that star is the best indicator of involvement of the package maintener or maintenance team over time
  • It seems to me that the “fragility” or “strength” of an app doesn’t really come from Yunohost team or package maintener. It comes from the upstream app itself.
    • If the app is very young or in version 0.x.x, the chances are high that it will move very fast, making each update a big pain for package maintainer that will basically have to rewrite his yunohost app every time. Chances are also high that the user base is smaller, which means that there will be less experienced packagers willing to use or keep that app up to date
    • If the app is very mature with a strong user base, you can bet that the Yunohost ecosystem will make sure to keep up, because it’s probably used by a lot of people including the app packagers themselves
    • Things start to get a bit weird with monster apps like Nextcloud, which is probably the most used app accross all Yunohost instances, but also probably the “star app” for which we have to wait the most at each update. On one hand, Nextcloud updates are crazy fasts with one or two major versions per year. On the other hand, the app is very complex to install
    • Finally, apps come in different “families” depending on the technical aspects behind. Yunohost team produced some “helpers” to help install apps using standard tech like php / nodejs and so on. Some apps are much more “exotic” in their tech choices, or less compatible with Yunohost’s own choices. An app using only standard tech, once you got it right for the first version, will be relatively easy to maintain since the install script will be purely based on helpers. An app using much more complicated logic to install itself is more likely to have troubles if the maintener behind all this is gone.
  • In the end Yunohost is nothing more than a Debian with a lot of helping scripts and UX. So yes, even if an app gets abandoned from its package maintener for some reason, you will still be able to update it. But in that case, it will very probably be very much useful for the community, and very much easier for you to update the package instead. Once you got the package logic, for an upstream app that is mature and not changing a lot, it’s actually quite easy to update a package !

Let’s take for instance your example of the Misskey package. From what I could check, it’s a very standard nodejs based app, and the install script is using only helpers. To update misskey for minor versions, you will probably only have to :

  1. Update the manifest.json file to put the new version number (super easy)
  2. Update the conf/app.src file to put the new tar.gz download link and compute its sha256 sum (once you got how to do, takes maximum 5 minutes)
  3. Create a pull request to the app repo
  4. Launch the CI test
  5. Wait for the package maintenance team to merge the pull request

Of course some versions bump will require just a little bit more than that, but you got the point !

[EDIT : I didn’t see that there were indeed a few CI failures from @ericg and @Tagada before merging their last update with success, but if you look into details the changes made are pretty minor (-10/+10 lines including some purely aesthetic changes), and the time you have to wait for is probably related to the CI server being a little bit slow these days and to the fact that they are maintaining a billion apps in parallel ! :rocket: ]

7 Likes

Thanks for that really detailed answer.

In summary - for me - this means that I don’t have to worry at all and can update the app on my own - if necessary.

That’s good to know.

I might take a look at the “package update procedure”.

1 Like

Well, if you use Yunohost you depends on other people benevolent time to maintain the package. (And also your time if you are willing and able to help)
That’s the point.
It doesn’t mean it has to be not (well) maintained. Quite a bunch of people (of volunteers) are doing a great job creating and maintaining those apps. It just mean it depends purely on other people free time and wiliness to help. No guaranty, that’s it.

Then it is yours to decide what you do with this, and if you prefer this option (and its drawbacks) against for instance the option of doing that work on your own.

What you can also do is setup a Yunohost server, and also install manually some apps (that will be “semi-integrated” into Yunohost) using the Custom app app. It might be useful in some use cases.
And as @Limezy said: if an app is no longer updated, 90% of the time you still can (with some technical knowledge obviously) do the upgrade process by hand without any issue or additional step required by some Yunohost integration specificity.

There are not defined because that’s not an official thing. And @Tagada said, they were such a list of “official” apps, but this system is no longer in place for various reason (documented somewhere in this forum).
But when watching github repositories, I can see which apps and updated most often, or to be more precise in which app people (in particular regular Yunohost contributors) invest more time and “workforce”.
What I meant is that those apps, for various reasons, get more interest than others and as a result as often update quicker.
But there is nothing official about this, nothing really planned to get this result.

As @Limezy said:

That’s not a guaranty either. But a good sign this app will have some kind of durable support.

That depends on every app, and will require some knowledge about how the app is updated, how the Yunohost package work, and more or less cautious actions (ex: if you upgrade all Yunohost app at once -with the default command for instance- then your custom upgraded app might be downgraded).

And as a general rule, any app which doesn’t require much more than “download this new source files” between two (minor/major) versions (as described for Misskey, while that’s not a so simple app in fact). Which is the case for most small apps, most of the time (one noteworthy exception being php version updates which sometimes causes some trouble).

2 Likes

Thanks! I would interested in guides about packaging and updating, the official documentation seems to be outdated?

A hackaton on 23rd April is planned to fix the documentation for contribution (and other documentation issues).

4 Likes

First update arrived and works perfect. Thanks to all contributor :+1:

1 Like