Upgrade 1.3.4 -> 1.20.2 worthy?

Haven’t been around here for a while, and been using 1.3.4 between a Mac and a Docker container smoothly with automatic upgrade disabled on both. Just seen that Syncthing travelled up to 1.20.2, so wondering if there is some worthy noticeable improvement in the engine that could push me to do the upgrade. Tried to read all the multi-years changelog but that’s doesn’t make it completely clear to me about the improvements. Also can I proceed without intermediate steps between 1.3.4 and the latest with no issues? Just with synchthing --upgrade Some things to be aware of upgrading Mac and Docker version? Thanks.

Why would you want to stick to an ancient version?

We thought every change we made over the years was a worthy improvement; why otherwise make an effort to do it?

2 Likes

Hey didn’t mean to minimize the developers’ work, instead a big thank you for the much beloved syncing software! I was just wondering if non-sticking to the older version is worth the risk of breaking something that is working well for me up to now. I understand there may have been security updates, and bug fixes, and improvements. I was referring mostly to something that’s noticeable like performance improvements. And I also mean what were in your opinion the biggest advancements between the two versions. Last but not least I asked if the upgrade can be done directly from one to the other and what kind of troubles (if any) should I be aware of.

2 Likes

Why would you want to stick to an ancient version?

it’s not that I wanted to stick to 1.3.4, there has been so much to life (excluding pandemias, moving home, etc.) I had so many things to think about I let something that worked well do its job by itself for a while…

1 Like

Yeah, there’s been a shitload of improvements, most of them good. If you want to look for the more important ones, look at the changelog for the .0 releases. Looking just at 1.4.0 that included a big database change that improved life for all larger setups.

You should be fine to go directly from 1.3.4 to 1.20.2. We intended it to be possible to do that. You’ll probably be the first and only to actually try it.

2 Likes

I can understand that such questions arise as it gives a sense of security when software is running smoothly and thinking about to “go away from it”. Feeling safe and thinking about doing an update, but where is the journey going? Others, like me, and probably most here, make all the updates, maybe even the RC’s. Errors occur very rarely, but are quickly rectified. In this respect, I would have good faith that nothing negative would arise.

I wouldn’t be quite sure about such a major step either, but if a database conversion in v1.20.2 works in the same way as with v1.4.0, that would probably be the main thing.

Much more interesting in the new versions are the features that have been added and optimized along with performance and system. In this respect, the update and its exploration is worthwhile in any case.

1 Like

All right, I can try to update and report back how it went. I was thinking about giving the Mac the first try then push the upgrade to the Docker container too, so:

  • if something goes bad on the Mac side at least do you know if can I go back to the 1.3.4 with Time Machine? in that case can you list the folder(s)/settings I have to restore from the TM backup? (I don’t mean the synced folders but the Syncthing app folders)
  • is there some known issue if the nodes are on different versions? Should I update both at the same time instead?

Thanks

If you are not quite sure, it would be possible to create a test environment first, maybe better then with other computers?

Otherwise only the backup of the data folder would remain on each device with the config, the key files, as well as the subfolder index-v0.14.0.db with the database, then the v1.3.4 could be reinstalled if necessary and the data folder restored again.

1 Like

One of the notable additions is “untrusted” devices (where the sync data and file names are encrypted on a remote device, but still properly synchronized), improvements in handling conflicts, improvements in the WebGUI (for example: direct link to edit ignore patterns from the folder status)…

To try an updated version, backup the config.xml, cert.pem and key.pem (you can also backup the https-cert.pem and https-key.pem, but those are only for the TLS connection to the WebGUI). See Backing and restoring a "primary" Syncthing node and How to save configuration of Syncthing.

Do the upgrade on both sides – many of the benefits won’t be seen unless both sides talk (close to) the same version.

If you don’t like what you get, replace the files you backed up on both sides and delete the database directory, then restart with the old version. The database will be rebuilt and it will look like the two sides are exchanging a lot of files, but if they were already in sync all you are seeing is the exchange of metadata as the two sides catch up.

No risk at all.

And do let us know how the upgrade goes, its an interesting data point to validate the developers’ efforts at maintaining continuity (a very laudable effort, which I am sure costs no small amount of frustration at times!).

2 Likes

I have been able to successfully upgrade to 1.20.2 on the Mac, but can’t figure how to upgrade Syncthing inside the Docker container on the NAS, it says “upgrade unsupported” when I launch the upgrade command from shell. I checked the env var inside the container and there is no STNOUPGRADE defined, but the hourly auto upgrade (set to 12) does not work too. How do I upgrade? Originally I installed syncthing/syncthing from QNAP Container Station.

You pull and run a newer container.

1 Like

But is there a way to keep the previous config? just backup the config folder and replace the new one?

The config and database should always be on a volume outside the container, our docker image and instructions do this by default. If you’re unsure how it’s set up you might want to make sure of that though.

1 Like

I also have the Docker versions running on my Synology’s. If there are changes in the config, I create an export of the configuration after each change. I haven’t had any changes lately, so I always work with the same configuration.

Since the database and configuration files are then also located natively in the configured directory of the volume, an update is always very quick. Stop and delete the container, delete the image, download the latest image, re-import the new container with the exported configuration and then activate the container. That’s all and is done within a few minutes.

I use QNAP and I think I have been able to install the 1.20.2 on the new Docker container and the config + database is on a share outside of it. I basically keep things as they were working with the 1.3.4 I used up to today on the same mount points. But when I run the container I get an entrypoint error. As you may have guessed I am not a Docker expert, so does someone know what this does mean?

image

I certainly don’t. I mean, it says that a command that the entrypoint script requires is not available, but that command is installed as part of the Docker build and the image works for me :person_shrugging:

The process is insider of the container. Which Docker version is installed, meaning the actual container software or APP version, which may not harmonize with the image.

Maybe the Docker setup fiddles with $PATH for some reason.

Are these correct? I copied them from the 1.3.4 container