Hi @gchen can you update “https://duplicacy.com/latest_cli_version” to 3.2.4 for Duplicacy Web updating ?
Many thanks.
In the meantime, you can tell web ui which CLI version to use explicitly:
OK but this adds an additional manipulation whereas now more than two months later there have been no problems requiring staying on the previous version
But there are no reasons to upgrade either. Once you pick the version and it works for you - why would you want to upgrade?
Every new update brings known number of bug fixes and new features and unknown number of new bugs. Unless bug fixes affect your workflow — there is no compelling reason to upgrade.
Hi,
just sharing my opinion here.
As far as I see, we have a “stable” and a “latest” tag. For me it would make absolutely sense to have always the latest version available referenced in the latest tag. People who don´t want or like to update should nevertheless use the “stable” tag, because for what is it used for instead?
If this is a problem, maybe a “dev” tag or something can be intoduced which references always to the latest build.
Meanwhile I update manually to 3.2.4, but it would be very nice if the application would recognize new versions.
I don´t understand your comment @saspus regarding the update. An update could include security fixes, new features and so on like in every other application as well. I mean, why is the application even further developed, when there is no point to update?
When more people are updating, this could also help the development team to iron out bugs etc.
Thanks for the amazing application and your hard work!
Appreciated!
Thanks and BR,
Chris
In the ideal world all users shall be by default on stable channel, and those who want newer features — latest. That was and is the intent of these channels.
In real world however it seems gchen updates the channel versions much more conservatively than some users expect, but if users want to get a specific fix present only in the cutting edge version without waiting — they can tell web ui to pick a version explicitly.
However, duplicacy CLI is stable, and updates are very infrequent, and that’s a good thing. Furthermore, this is a client software, running in the most trusted of environments, so it’s unlikely that there will be any security fixes in duplicacy itself or dependencies requiring immediate response. Historically, all updates were due to things changing around Duplicacy — like Google drive changing file access permissions to existing apps, or Dropbox breaking.
Therefore, it’s not a bad approach to pick a version that works, and stick to it: fixed version is not much different that a very slowly updating “stable” channel, and safer: this utility handles my data, and if it works for years, to update I need much better arguments than “hey here is a security fixes” or “hey look at this new compression scheme” — specifically because any update brings unknown number of unknown bugs, and you want to be ultra conservative with your backups.
Thanks for your reply.
I fully understand your points and I agree and disagree at the same time. As stated above, I would handle it a bit different, but it is not my project and therefore it is totally fine as it is.
Thanks for commenting and sharing your opinion.
Best regards,
Chris
1 Like