[Dlang-internal] Regression control & breaking changes policies

[Martin Nowak via Dlang-internal]

On Saturday, 10 December 2016 at 09:08:53 UTC, Walter Bright 
wrote:
> The problem is I just don't know what is different between the 
> branches, master, and what I have. The confusion about which 
> bugs are fixed in which branch has also come up.

Easy as pie, we can merge master into scope and you're up to date 
with everything.
A feature shouldn't have anything to do with master, the fact 
that some scope work was already released, indeed complicates the 
situation a bit.

> With a new PR based on what I have, things become 
> straightforward. I can ensure the bugzilla issues are fixed and 
> the autotester passes it and it all works with the latest 
> Phobos.

Please not, it creates the old deadlock that we cannot 
incrementally merge your work on that feature without risking a 
completely broken release. The only reason we could merge the 
first 2 chunks after a somewhat coarse review without extensive 
testing was the feature.

Please bear with me for a while, adopting a better git workflow 
will help us a lot to improve quality of releases and scale to 
more contributors.

Just a short summary of how feature branches are supposed to work 
atm.
This is not set in stone, so if you see improvements, please 
mention them.

- a feature is implemented in a single branch or multiple 
identically named branches across the dlang repos (dmd, druntime, 
phobos,...)
- testing and building is done using all of those branches
- the master branch is used as a fallback if one of the repos 
doesn't have a branch of the feature name
- Travis-CI, CyberShadow/DAutoTest, and the project tester 
(ci.dawg.eu) will work with feature branches, not sure if someone 
can manage to add support to the auto-tester
- once a feature is complete (implementation, docs, final 
testing+review), we merge the complete feature back into master, 
so it will be released soon after that