On 10/12/17 19:50, Jonathan M Davis wrote:
On Thursday, October 12, 2017 14:39:27 b4s1L3 via Digitalmars-d-announce
Also i'd like to say that the policy that is that regression
fixes are commited on stable and that the fact that they only
come to master in a "sync operation" is a problem.
In the travis yaml we have to test dmd, dmd beta (stable, not yet
released) and finally dmd master (current working tree). The
policy should be changed so that regression fixes are commited to
both master and stable, allowing to decrease the CI complexity.
The problem is mainly that testing a project with dmd beta is
pointless. It's only useful 1 or 2 weeks before a release, which
happens , let's say, 4 times per years, leading to a waste of
computing resources at the CI service.
With reg fixes put in master at the same time that in stable,
testing 3 versions of the DMD compiler would not be necessary
anymore, i think.
I don't know what the best way to handle committing regression fixes is, but
I did find it annoying recently when I ran into a bug on master that I'd
fixed on stable, but the fix hadn't been merged over yet. The fact that the
fixes are delayed on master makes master buggier than it would be otherwise,
and a number of us use master as our primary compiler.
- Jonathan M Davis
At work we branch out of stable (not yet released) and fix the bug.
Merge branch to stable and then merge branch to master. Works pretty
well. As long as you don't merge things into stable that you never
intend for master.