Your Ubuntu machine was either running the previous beta/experimental, or just a canary that was old enough to be on the same database version as the “new” beta.
If your Windows machine and Ubuntu machine had both had the same Canary version both would behave the same.
I am not sure how we should communicate this, but the idea is that each channel is independent. That means, if you are on beta, just stay there and you will get the most stabe/tested updates. Likewise goes for experimental, if you stay on it, all works.
Generally, the canary will have the latest fixes and updates, but occasionally issues. Normally, you would be able to change from a canary to a beta, but for this release we had a short time window to warn Amazon Cloud Drive users. A problem was detected with the FTP provider in the canary, so we decided to delay all other changes than the warning, so even tough the version numbers increment, they do not follow each other.
This is a design decision, and we need to be able to run different channels so we do not delay or prevent updates to the canary while releasing a beta.
We could be more clear about the version numbers, such that they convey “newer than”. My idea with the number was to simply increment from 2.0.4.5, but 2.0.4.6 was taken, so I just went to the to the next number.
I could have used 2.0.4.6, but that would also be confusing as there would be two different builds with the same number but one with a canary tag and one with a beta tag.
You are the first person to request this information 
But I think you have a point. We should perhaps force increment the third value (i.e. we should be on 2.0.5.x for the canary and 2.0.4.x for the beta) to indicate database schema changes.
It has only been slightly problematic when people want to downgrade a canary, but here the problem occurs because you changed the update channel (or manually installed the beta).
I have not seen you even attempting to communicate this. It is so contrary to the practices in other software projects that you really need to make it clear.
How about the first official release, can one upgrade to it from any branch or just the beta branch?
It is very much a normal practice to inform users about database upgrades in every release they occur - so normal that I expect it to be the default.
Close, but not quite. I had for a long time had the latest beta, 2.0.4.5, on the Ubuntu machine (on Windows, that was the plan as well, but that version just could not be installed, so I chose the latest Canary instead, and never had regrets). However, I had installed the latest canary on the both machines recently, because I was trouble-shooting a problem on the Ubuntu machine. I even did a downgrade during the trouble-shooting, but ended up having the latest canary and once I had figured out what the problem was (my own mistake), I managed to run the problematic backup a few times. And then I installed this new beta. And then backups succeeded fine, no problem at all.
The only explanation I can come up with is that after installing the beta, I may have forgotten that the Ubuntu machine was still running the previous version. The Windows installer forces me to shut down the currently running Duplicati processes, but on Ubuntu that does not happen, at least not when I make the installation from a downloaded deb package.
Should I create a bug report or feature request for shutting down the processes also on Linux?
I’m not sure if that difference is a feature or a bug. Linux usually allows updates to software without interference with running software. Meanwhile windows often require restarts to apply.
Forcing it on both would probably be more user friendly but I could see it annoying some experienced Linux users.
Forcing is not necessary. Showing the processes to user to remind that they are running the old version would be enough.
Could be a fair compromise
When using Firefox Nigthly, a switch to the stable release is a downgrade as well. We do not have nightly builds (my fault) but the same logic applies to canary builds.
Can you give an example of where such information should be placed? Maybe a specific wording that would have made it clear to you?
The experiemental and beta branches for sure. The canary branch may have drifted (it usually does) in the time we wait for last-minute feedback on the releases.
Can you give an example of other software that does this? I am unsure how to present the information, so I would like to see.
My experience is from published releases, which are in production use. Most cases I can remember are software I have needed at work. Thinking of OpenSource software that I use at home, I can mention GnuCash, which is mature enough to not have database upgrades very often. When it does, users are informed loudly about it in release announcements, release notes, and … I was trying to check the download page, but the site seems unreachable right now. The release annnouncements and releases notes are prominent enough, though. I always check them for incompatibility information.
I can understand that while Duplicati is still in development phase, my nagging may seem nit-picking. Now that I think of it, it is possible that when I first installed Duplicati2, I did read and understandd that the channels are separate. But that was a few years back, and after that, nothing has reminded me about it. Originally, I had planned to use beta releases only, but then 2.0.4.5 failed to install on Windows, and somehow I got derailed into choosing canary instead of experimental.
The best way to to remind the user is the same place where you describe the changes in each release, briefly or not. In your case, that seems to be the download page. The minimum I would expect to see there is the database version. That alone would have alerted me to check again the difference of the channels.
I think this is where Duplicati wants to go, and I’ve heard a wish for more frequent betas than current plan.
Perhaps it’s time to think about how to juggle competing objectives:
More frequent betas, also avoiding pushes for “one more fix”
Is a sense of upcoming beta good, or a contribution-blocker?
I’m not bold enough to suggest a specific calendar schedule
Ability to hot-fix betas for things that can’t wait until next beta
Outside disruptions happen, and “test escapes” can as well
Use usage reporter data to track canary/experimental pickup
A faster beta cycle will mean less time to hope for field tests
Encourage and develop better-trained volunteers to help test
Ideally they also know how to collect data, and maybe debug
Rare problems seen only in the field are extremely hard to fix
Simple enough version methods to not confuse contributors
Duplicati can’t train everybody the way a big company might
A few contributors who know Git well enough to do backports
Probably don’t want to get excessive about parallel branches
Latest beta gets supported, but that might include a backport
Release numbers that don’t contain unexpected surprises…
I wish 2.0.4.23 came out 2.0.4.5.1, but we’re out of numbers
There was also the idea of third field going up on DB change
I’m wondering when second field will ever go up. Wasted 0?
Leave gaps in number sequence for future use, e.g. 2.0.4.6?
Document release warnings and oddities as discussed here
DB version info is good, but also say what it means to users
At the moment, it looks like the way three channels emerge from one master is to keep canary open, then lead developer does an experimental as a beta pre-release, then a beta happens. Experimental isn’t open to all changes, as seen here. It’s not clear how open canary is. Huge changes and DB changes might risk preventing an experimental-beta restart-from-canary if that becomes needed. I don’t recall if it’s happened.
This is all part of growing pains. Duplicati is (slowly) becoming higher quality, and to maintain its level while moving forward (can’t afford paralysis from fear of breakages) is the challenge. Is this worth a discussion? Technically it belongs in Developer category but I’ll start here because there’s an experienced VCS person.
Personally, I’ve found that branches and version control can be a headache. Maybe smaller steps are best for a project this size. While there’s a core of regular contributors, there are even more less frequent ones.
What if versioning was changed so that the 4th number is reserved for special cases like this. Normal incremental releases would increment the 3rd number instead. 4th number would normally be a zero.
Seems like an invitation to chip in. I do have quite a long experience with various sw development environments and source code management tools, but my experience is more on the technical side, and less, if at all, in the branching strategy planning departement. On the other hand, I have for too long worked for companies that have tied their hands to one or more commercial (and expensive) VCS tools, and never found the wisdom and courage to take the big leap to Git, which I have for long considered superior. Since I don’t have any heavy-duty experience of Git, I can’t pretend to be a technical expert on it.
Anyway, what I understand from your list of objectives is that you are getting to the point when you (the project team) have to get serious about the difference between fault management and change management. These are not terms I invented, but there are so many different definitions for them, that I have to explain them the way I have come to understand them.
Fault management is triggered by failure reports, which come from testing or from users of a published release. For most failures, one finds an explanation that does not involve any fault to be fixed. Some failures turn out in analysis to indicate an unexpected behavior. If there is a specification of expected behavior, then fault is a deviation from the spec. Otherwise, it is just an unexpected behavior. Once a fault has been identified, it is then prioritized and maybe some day it gets fixed.
Change management, on the other hand, begins with all new expectations. We may take time to work out a specification, or we may write a few words to each other in team meetings or email, and we may agree on a to-do list. Whatever the method, change management is about going forward, from an idea or a possible request from users, to a specification or at least agreement on what we have on our to-do list, to implementation, to testing, and finally to publishing a release (and release management is change management in large quantities).
Change management is all about going with the flow, whether waterfall or iterative development or no model at all. In contrast, fault management is about turning back to what we already cemented into a release – be it project-internal release, test release or production release – and tearing it up to fix the identified deviation, and then wrapping it up again. Fault management is all about going back upstream, against the flow. It is the backcurrent of development flow.
Both fault management and change management require tools that support communication and storage of shared information, be it failure reports, fault identification, change requests, feature specs, to-do lists, release plans, or whatever. These tools you have already chosen. What is missing is proper distinction between the forward flow and the backward flow. You may not have had a need to make the distinction yet, but the clock is ticking. You need to get it sorted before publishing an actual release. The nature of the software you are working on is such that your users will depend on you a great deal.
How all this then translates to the specifics of release versioning, and possibly a branching strategy, is difficult to give advice on from outside of the team.
The Linux kernel went to a fixed and predictable release schedule to avoid having developers feel like they need to rush to get their changes in. However, I think we would need to improve our testing/logging in order for this to really work. Unfortunately, the more serious and annoying issues currently are the ones that aren’t easy to reproduce.
I wouldn’t let concerns about the version control system impede how we want to release and support different versions/branches. Git was designed with this exact workflow in mind.
Your dependency on cloud services means that this situation may not be unique, there may come other cases that you urgently need to inform your users of. Maybe you could consider enhancing the mechanism you already use for informing users about new versions and add a another channel so you can dynamically inform users about topical issues without having to push a new release every time?
I don’t have a separate server, so it took a while before it occurred to me that when client and server are on different hosts, it could be even more important to stop the processes at both ends. Does it matter in which order they are upgraded? If there are many clients, how important is it to upgrade them all at the same time? Does the client warn the user if server has higher version? Does the client warn the user if client and server have been installed from different release channels?
People do this? I mean, I access some Duplicati instances remotely via web browser, but that’s it.
I realized after posting that the client/server wording may be off. I’m just so used to clients and servers that I forgot this is a little bit different kind of case.
It’s similar enough that Cache busting for new versions #3481 was added to try to get Web UI updated. Unfortunately the change isn’t in 2.0.4.5 beta but it did make it into v2.0.4.6-2.0.4.6_canary_2018-12-11 therefore it should be in v2.0.4.21-2.0.4.21_experimental_2019-06-28 and in next-heavily-updated-beta.
Independent project duplicati-client will likely have it harder if the client-server interface ever changes…
After I reinstalled the latest canary that I had been using before I mistakenly installed the latest beta, I now realize that one big reason why I made the mistake is that Duplicati keeps informing me about the new release, although my choice of channel is not beta. I have never upgraded via the web UI, so I don’t know at which point exactly Duplicati uses the channel setting, but I can tell you it should be before informing about the new version. At minimum, the notification should indicate that the new release does not match my chosen channel.