[Development] Branching for Qt 5 repositories

João Abecasis joao at abecasis.name
Fri Sep 28 10:28:26 CEST 2012


Laszlo Papp wrote:
>> 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.

No it is not a release. The point is features are developed outside
shared branches until the point where they are ready for wider
exposure. It doesn't mean they won't change. But it does mean the
feature does something useful (i.e., is not half-broken, doesn't break
the build), has tests for the functionality it offers that will be run
by the CI gate, has minimal documentation to make it useful to
developers wanting to try out or review the feature.

Merging a feature to a shared branch means you are publishing it for
others to try out and see. The fact that the initial branch is still a
development branch means the API/ABI is not immediately set, so it can
change. Typically, documentation can be incrementally improved from
then on, but it's important to have something to begin with.

As much as possible, break big features into smaller incremental ones
that can be taken in one at a time and built upon.

Again, "complete" is not the same as "frozen". And releasing to a
shared branch is still meant to gather feedback and improve.

Cheers,


João



More information about the Development mailing list