Release D v2.076.1

Adam Wilson flyboynw at gmail.com
Fri Oct 13 05:45:44 UTC 2017


On 10/12/17 19:50, Jonathan M Davis wrote:
> On Thursday, October 12, 2017 14:39:27 b4s1L3 via Digitalmars-d-announce
> wrote:
>> 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.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;


More information about the Digitalmars-d-announce mailing list