[Development] Branching for Qt 5 repositories

[Laszlo Papp]

> That's the point: it's not the most common way, at least not in Git. If you
> take for example Git's Git, the "master" branch contains the latest release,
> whereas the next release is in the "next" branch.

Well, you can say that it is not common, but I could enumerate quite a
few examples including KDE, gnome, webkit (trunk?), and numerous other
big projects where trunk/master is the development branch. Another
variant is what Loaden mentioned, but I do not prefer the initially
proposed way in this thread.

Speaking of common way, I would stick to master or "next". As I have
always been using "master/trunk" for this purpose, my personal
preference is "master/trunk". This would also be the least distractive
to current gerrit, but that is probably not the main leading point,
just yet another advantage. The second preference of mine is "next".
No preference for "dev" exists on my side.

> No, I really do and those qualifiers are required, but note that they apply to
> each feature individually. That is, if you want to merge the command-line
> parser, it needs to be feature-complete, working, documented, tested and a few
> more qualifiers (cf. Qt Project's "Technical Fit") before I or anyone else
> should click that +2.

If those all fully apply, I would call it "release" since there is
nothing to fix anymore or stabilize since it is "completely". My point
is that there may be bugs on certain platforms where it is not well
tested, or the documentation is written and approved by developers and
cannot get better until it is released to the public for further
feedback and improvement.

>> 1) Bug that was already fixed in the development branch.
>
> Not a problem. That indicates that either the fix was submitted to the wrong
> branch or that this particular fix did not apply to more stable branches. If
> this person developing the new fix comes up with a fix that is acceptable for
> the stable branch, then it makes sense to accept it, in spite of a different fix
> existing in dev.

Even if the fix does not apply against the stable or release branch,
the fix in dev might contain the idea which needs to be adopted. That
can occasionally spare a lot of time for the contributor trying to fix
the issue in stable or release. Like I said, perhaps this could be
avoided with a very good workflow documentation, but then there is
always the factor, not everybody can read that carefully from A-Z.

>> 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 don't think it's a problem either. This developer may develop new features
> on top of the stable release (I used to do that in Qt 4), but should pay
> attention to the development branch. Qt is big, but it's not hard to pay
> attention to the areas one is developing on.

Well, it happens to many from time to time even with top developers
occasionally. We always see this around due to our human nature as we
are not perfect. We make mistakes if we have additional factors like
this. So "should pay attention" is yet another fact for confusion,
misunderstanding, and overlooking.

I do not have a strong opinion at this point about either too much,
but i would like to reveal this drawback to be fair as you have not
mentioned that in your initial email.

> 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.

Also, this is a bit in contradiction with this qualifier, at least for me:

"[*] alpha quality is feature complete, working, documented, tested, etc."

Laszlo