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.