[Development] Branching for Qt 5 repositories

[Thiago Macieira]

On sexta-feira, 28 de setembro de 2012 00.54.34, Laszlo Papp wrote:
> > 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.

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.

The use of master to mean the in-development version comes from the way we 
used to use Perforce: the //depot/qt/main repository was the development 
version, like a Subversion's trunk repository or a CVS's MAIN branch. When we 
switched Qt to Git, we mapped master = main and that development style was 
inherited in KDE.

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

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.

Feature branches are not drawn. Those are developed however the devs working 
on the feature want to. But they need to reach the alpha quality before asking 
for merging that branch.

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

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.

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

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120928/8f817eea/attachment.sig>