[Development] Branching for Qt 5 repositories

[Laszlo Papp]

> They are:
>  - dev: unfrozen branch, containing alpha-quality[*] code that is ready to go
>    into beta testing at any time

What is the reason for calling this "dev" instead of "master" which is
more common for developers, and it would not have an impact on the
submitted changes to gerrit even in a year or more.

>  - stable: feature-frozen branch, containing beta-quality or better code
>  - release: deep-frozen branch, for which only the release team should
>    approve changes, containing code about to be released
>
> [*] alpha quality is feature complete, working, documented, tested, etc.

I think this is a bit excessive for an alpha quality description
unless you do not mean "fully" before each of those qualifiers.

> Note that there is no "master" branch any more. In addition, the default
> branch  (the one that gets checked out on a new clone) will be either stable
> or release, but definitely not dev. The intention is that new developers who
> clone Qt repositories for the first time are presented with a stable codebase
> they can begin working on, bugfixing and even developing new features for.

This leaves me one question: what if someone would like to fix a bug
or start working on a new feature no matter what the stable or release
contains at that very moment? That person may miss:

1) Bug that was already fixed in the development branch.
2) Feature that may have been already put into the development branch,
but it is not yet in the stable or release due to its current quality.
However, a new developer should not reinvent that due to a mistake.

I mean the workflow is that for many people, especially when bug
found: clone, fix, and build in general. Perhaps this could be aided
with a good documentation in the end. I do not know, this situation
has just come up to my mind. :-)

Laszlo