Safe to update across versions far apart?

[jnano]

In terms of wallet, chainstate, and block data, is it okay to update Core across versions years apart?

Specifically, from version 0.18.x to 28.x, which are 5-6 years apart.
With pruned block data.

[BitMaxz]

I think it's safe but it's recommended to keep up-to-date if there's a recent version release.

And before upgrading the core to the most recent version, always make sure to make a backup copy of the wallet.dat file just in case the core has some issues after the upgrade, you can later fix the issue and recover the wallet.

[nc50lc]

Specifically, from version 0.18.x to 28.x, which are 5-6 years apart.

Your legacy wallet should still be compatible with v28.1.
But not in v29.0 v30.0 once it's released, you'll have to migrate it into a descriptor wallet.

For your UTXO Set and Blocks, the versions aren't too far apart and there's no incompatible changes listed in the Release Notes.
To check it yourself: Meticulously read every release notes from v0.18.1 to v28.1, the part where it says: "How to Upgrade" where forwards/backwards compatibility is usually mentioned.
But if you can backup the whole datadir (since it's pruned anyways), do it in case something happens with during upgrade.

[LoyceV]

But if you can backup the whole datadir (since it's pruned anyways), do it in case something happens with during upgrade.

That's what I wanted to add too It's only 15 GB, and fits even on a USB-stick.

[jnano]

Thanks.

But not in v29.0 once it's released

If it won't be capable of converting it as needed, that's a surprise.

Meticulously read every release notes from v0.18.1 to v28.1

Too bad there's no all-in-one changelog.

It's only 15 GB, and fits even on a USB-stick.

Yes, though depends on your set prune size.

Though I'm wondering more about potential "silent" problems.
In theory, one would expect it to explicitly alert if something's not compatible, leave the data be, and exit gracefully.
Core is typically pretty elaborate in data compatibility checking, and logging / alerting.

it's recommended to keep up-to-date if there's a recent version release.

I think it's pretty common in Bitcoin land not to update quickly.
I'm not sure where one can find stats about "general" users, but stats on 22K nodes do show a spread of versions.

[promise444c5]

I'm not sure where one can find stats about "general" users, but stats on 22K nodes do show a spread of versions.

Try Bitnodes.io Maybe it could be of help..

though depends on your set prune size.

So far you have the required backup space then you can always archive it.. you can also test it by running it directly from the external drive before you start the upgrade as the copied folder  could have some corrupted files sometimes, you can do that by changing the -datadir path to the new external  drive path , if it works then you can revert the changes made and go on with your upgrade... make sure you revert it though.

[nc50lc]

But not in v29.0 once it's released

If it won't be capable of converting it as needed, that's a surprise.

Update; there was an update in the proposed timeline edited 3 weeks ago that I haven't checked:
You wont be able to load your legacy wallet in v30.0 instead of v29.0. In that release, Bitcoin Core will provide instructions on how to migrate your old wallet.
But if you want to do it now, use "File->Migrate Wallet".

Though I'm wondering more about potential "silent" problems.
In theory, one would expect it to explicitly alert if something's not compatible, leave the data be, and exit gracefully.
Core is typically pretty elaborate in data compatibility checking, and logging / alerting.

Those are more typical to updated config, network, etc. which depends if you're using such options.
Like for example, v28.0 and v28.1's update in bind settings which could break some setups.

But for the Blockchain and Chainstate compatibility, it's should be explicitly noted in the release notes.

[apogio]

I'm not sure where one can find stats about "general" users, but stats on 22K nodes do show a spread of versions.

You must refer to network's statistics. If so, you can check this website: https://bitcointicker.co/networkstats/ or the one that promise444c5 refers to below:

Try Bitnodes.io Maybe it could be of help..

If, on the other hand, you want to check statistics on your node's operations, a very cool project is https://statoshi.info/, which is implemented by Jameson Lopp.
There is a great amount of cool stuff to see there.

[jnano]

Seemed okay.
The only minor log warning was about the ban list file, which changed to JSON format in v22:

Code:

banlist.dat ignored because it can only be read by Bitcoin Core version 22.x. Remove "...\banlist.dat" to silence this warning.

By the way, one unrelated oddity are a few stray random-looking but fixed characters at the end of some log lines, ones prefixed with "init message:".

[nc50lc]

By the way, one unrelated oddity are a few stray random-looking but fixed characters at the end of some log lines, ones prefixed with "init message:".

Those shouldn't be random-looking characters but "Ellipsis", the single-character triple dots.
Perhaps your language doesn't support that character.

I double-checked my logs since v28.0 to v29.0 to be sure and it's not showing as gibberish character.