What's the latest version and why do different VLC sources list different latest versions?

[lwc]

https://www.videolan.org/vlc/download-android.html states 3.5.4 but then without blinking it immediately links to https://code.videolan.org/videolan/vlc- ... aster/NEWS which seems to indicate 3.5.7 is the newest.

Meanwhile, https://www.videolan.org/news.html lists 3.5.0 (from 2022) as the newest...

In Google Play Store itself it seems to be 3.5.7 (depending on your device).

It may help if the NEWS above had dates in it, which could then be crossed with the store's listing's date.

[Aza]

The current version is indeed 3.5.7. As stated in the changelog, this version has no feature or bug fixes and its sole purpose is to unlock our issues with the Play Store. We will push the 3.5.6 and 3.5.7 version on our website at one point, but we didn't have time for that.

About the news on https://www.videolan.org/news.html we typically update this only for major versions, that's why it seems outdated.

The NEWS has in fact dates if you look at it in our code repository: https://code.videolan.org/videolan/vlc- ... type=heads
But I agree, it's not optimal.

[lwc]

By now it's even more confusing - both https://code.videolan.org/videolan/vlc- ... aster/NEWS state 3.6.0 is the latest version and https://code.videolan.org/videolan/vlc- ... type=heads state 3.6.0 while the actual Google Play Store entry is still from October 2024.

Shouldn't you reflect a stable changelog version only after it's officially downloadable? I mean, even https://www.videolan.org/vlc/download-android.html still offers a direct download of 3.5.7.

[Aza]

We change those files when we build the release. After that, there is a review time on Play Store's side. We just released the 3.6.0 version half an hour ago (it's a roll out so you may not have received it yet).

[lwc]

The Play Store entry indeed shows this week's date now (it has a standalone date regardless of one's devices). Does it mean you do have the power to push it there?

[Aza]

I don't understand your question. If you're asking if I the one in charge of releasing VLC for Android, yes I am.

[lwc]

I just wondered when you wrote you released it half an hour ago was it because of my post?

In any case, the Play Store entry shows this week's date, but still downloads the previous version. Does it mean they update the date despite not finishing the review (which was submitted at the beginning of the week)?

[Rancid]

Is there no way to automatically update https://get.videolan.org/vlc-android/
Is there not a way similar to how artifacts are always up to date,
To Publish latest folder to public ?
Artifacts folder is updated automatically,
https://artifacts.videolan.org/vlc-andr ... tly-arm64/
https://artifacts.videolan.org/vlc-android/release/
But, package is not official.

[Aza]

I just wondered when you wrote you released it half an hour ago was it because of my post?

Now, we schedule releases internally, depending on our ability to manage any problem that may happen. That's why it's been published on a Monday afternoon in our timezone.

In any case, the Play Store entry shows this week's date, but still downloads the previous version.

We currently are in a roll out. The app is only updated for a percentage of our users (5% today) to make sure it's stable enough before sending it to our millions of users.

Is there no way to automatically update https://get.videolan.org/vlc-android/

What do you mean by that?
- A release version published daily? If yes, no we do not provide that.
- An in-app "auto update" to get the latest published version? We could technically do that, as long as the app has not been downloaded through the Play Store.

But, package is not official.

This is on purpose:
- it prevents us to sign it with our release key which is a manual operation
- it allows the users to install it besides the official version, make some tests and the get rid of it without affecting the official version.

[Rancid]

We currently are in a roll out. The app is only updated for a percentage of our users (5% today) to make sure it's stable enough before sending it to our millions of users.

Is there no way to automatically update https://get.videolan.org/vlc-android/

What do you mean by that?
- A release version published daily? If yes, no we do not provide that.
- An in-app "auto update" to get the latest published version? We could technically do that, as long as the app has not been downloaded through the Play Store.

But, package is not official.

This is on purpose:
- it prevents us to sign it with our release key which is a manual operation
- it allows the users to install it besides the official version, make some tests and the get rid of it without affecting the official version.

No, I mean from previous experience usually when you push a new tag it get built like 3.6.0 is already built and probably already on https://get.videolan.org/vlc-android/ but maybe hidden from public.
As many times previously the dates shown on server is very close to tag push, but it can take much much longer for public to have access to it.
Maybe this is part of your roll out strategy, but a small percentage would get apk directly from site.
So, why not make it available immediately as part of the script that is scheduled when you gush new "stable" - https://code.videolan.org/videolan/vlc- ... mits/3.6.0 - tag or "beta" - https://code.videolan.org/videolan/vlc- ... 6.0-beta06 - tag
For
https://get.videolan.org/vlc-android/
And,
https://get.videolan.org/testing/android/
Respectively
But, an in-app auto update feature can be interesting for version obtained directly, since you already have it implemented for nightlies, so it would be a small change for releases from site

[Aza]

So, why not make it available immediately as part of the script that is scheduled when you gush new "stable"

Because the person who has access to that part (not me) is very busy

[lwc]

We currently are in a roll out. The app is only updated for a percentage of our users (5% today) to make sure it's stable enough before sending it to our millions of users.

Is it by your choice or does Google do it for every app? Either way, if this 5% is random how do you know they're the type of people to make enough noise when something goes bad?
When at least roughly do you estimate the roll out to be over?

[Aza]

Is it by your choice or does Google do it for every app?

It's a choice. You can skip the roll out when you release an app. But with tenths of millions of users and an app blocked from releasing for almost 2 years, we play it safe this time.

Either way, if this 5% is random how do you know they're the type of people to make enough noise when something goes bad?

Exactly that. This figure has been chosen to be larger than our beta user pool and small enough to prevent impacting too many users.

When at least roughly do you estimate the roll out to be over?

We won't release 3.6.0 at 100%. There are some crashes that need to be fixed. We still need to fix one crash before doing a 3.6.1. If it's stable enough, the roll out will progressively increase until it reaches 100%

[lwc]

Either way, if this 5% is random how do you know they're the type of people to make enough noise when something goes bad?

Exactly that. This figure has been chosen to be larger than our beta user pool and small enough to prevent impacting too many users.

Thanks, but what I meant was if the 5% is random, how will you know it crashed on them, etc.?
When you do a beta, you enlist in the first place people who are likely to report on problems. But random means you may fall on people who don't even want or know to report problems.

[Aza]

We use the anonymous crash reports provided by the Play Store. As you said, our beta tester pool is not random, therefore they differ from a random pool of users and we definitely find new bugs at full release time due to these differences.

What leads to that:
- Beta testers have newer devices with newer Android versions
- They are more tech savvy
- Even if they are hundreds of thousands, they are not always enough

BTW, when we finally go out of beta, we also push the new version to our beta track. So they all get it at time our roll out release starts.