Release: 2.0.4.23 (beta) 2019-07-14

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.

1 Like

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.

1 Like

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.