QtMir branching strategy

[Alan Griffiths]

On 07/08/15 16:37, Gerry Boland wrote:
> Opposing argument is that the CI train system forces us to keep quality
> high. I don't see any reason why changing our branching model would
> cause quality of releases to degrade. One could argue that it means that
> the quality of each intermediary code change could drop, but I'm
> prepared to take this theoretical risk to gain a definite improvement in
> development speed and making releases easier.

I guess it is a matter of discipline, but IMO the current state of
development should kept in a state that can be released. To me that
seems easier if there's an integration branch/trunk representing
completed development, not a collection of merge proposals that need to
be consolidated at release time.

Merging work when completed also shortens the feedback cycle between
doing the work and detecting conflicts or other incompatibilities with
other changes.

> Are there objections or opinions about this?

I approve it.