“It will never be updated” is a property that is just as true/false on Windows or Mac applications. What do people do? They build self updated into their programs!

And like you said, Google does it. They do it with a single deb you click on.

I feel like package managers on distos are a thing that kinda make people forget that applications can be distributed “normally” outside this chain.

This is a fair point, and valid and true.

However, for better or for worse, it is not the Linux way.

Maybe it should be, but it isn't.

I can't think of a single Linux app that self-updates this way. I suspect that on most distros, permissions issues would prevent it.

I also suspect that if it were easy, Google would have done it. It is not a company that does things the hard way for fun.

Packaging apps as distro-native packages isn't trivial but there's tons of existing tooling for it. Ditto for hosting repos.

So what Google did is package stuff so that it adds its own repos when you install it, and then it is left up to the OS to keep it updated.

That to me says that that was an easier job than writing self-updating Linux apps, like Chrome on Windows or on macOS.

How many of these inexperienced linux users are running Arch linux?

It is an _example_.

OTOH do not forget that Arch is a family of distros now, not a single distro, just as Debian is.

In fact I suspect that it is the 2nd biggest family of distros, after Debian.

Debian encompasses many dozens: Ubuntu, plus dozens of Ubuntu derivatives including Mint, Elementary, PopOS, ZorinOS, Linux Lite etc.; LMDE; Devuan; MX Linux; SpiralLinux; etc. etc.

Arch now encompasses at least Manjaro, EndeavourOS, Garuda and more. https://wiki.archlinux.org/title/Arch-based_distributions

But that is not the point.

The point is that _tens of millions_ are running non-Debian-derived distros, mostly ChromeOS and CloudReady/ChromeOS Flex.

Offering a .deb package is _not_ a useful approach to offering a generic Linux package, no.

The RHEL and SuSE family is definitely bigger than arch and arch adjacent distros but I agree with your point

Yes, that's true.

FWIW, I have tried both the Snap and AppImage versions of TB 102.

Both were very easy to install. The problem is that Snap confinement meant that TB could not see my existing profile. I just got the first-run wizard.

This did not affect the AppImage, which is working well.

The "right thing" is submitting a patch to popular distros to have your package included in the repos.

IME: it's always application devs who are upset about this, not users.

No, I disagree. I can see at least 3 reasons:

[1] That will happen in time anyway. This is a flagship app.

[2] I would not expect any distro to include a major version in its stable release. So, even if they do that, it will take months to percolate out.

[3] When it happens, it will need an OS version upgrade.

This is a standalone app release, not an OS release. It is in many OSes and it will make its way to them in time. You are conflating 2 different things.

The question we are discussing here is: I run T'bird on my own box, and I want to try the new version; how do I do that?

There are 2 possible solutions to this: either provide distro-native packages (as Google does; this is mainly appropriate to proprietary apps, which T'bird is not); or, provide some kind of cross-distro package. Since both Snap and Flatpak need support tools installed, and AppImage does not, that makes AppImage the best choice, IMHO.

Snapcraft and Flathub will do their own thing in time.

On which note, T'bird 102 is already on Snapcraft, but it does not pick up existing T'bird settings or profiles.