6-weeks release cycle

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Fri Jun 5 01:28:26 PDT 2015


On Friday, 5 June 2015 at 06:42:06 UTC, Rikki Cattermole wrote:
> And shouldn't the CI be doing regression testing already?

The autotester runs the unit tests that are in druntime, Phobos, 
and dmd. It catches a lot of stuff and generally prevents us from 
merging bad code. But it can't possibly catch everything. It 
catches the stuff that we thought to specifically test for and 
bugs that were fixed (since unit tests are usually added for bug 
fixes). But it's not that infrequent for something _new_ to break 
that's never broken before and is subtle enough that it doesn't 
get past all of the tests - especially when you're dealing with 
changes to the compiler.

To catch all of that stuff before it goes out the door in a 
release, we need to test a _much_ larger code base than just the 
standard stuff - which is part of why we have betas. We want 
folks to try out their projects with the betas so that we can 
catch the stuff that we missed before it gets released in an 
official release. Simply grabbing an arbitrary commit and 
declaring it a release just because it's at about the time that 
we want to do a release would be a disaster. Too much gets 
through as it is simply because not enough folks test the betas 
and report what they find. _All_ of that would get through if we 
just picked a random commit and declared it to be a release.

_Maybe_ someday our test suites will catch such a large portion 
of the regressions that we won't actually end up with any 
regressions getting out, but I doubt it. Even large, heavily used 
projects like gcc or KDE end up with regressions getting out, 
much as they try to avoid it. But like them, we need to do our 
best to have releases which have been tested well enough via 
betas and whatnot rather than just releasing stuff simply because 
it's a certain date.

- Jonathan M Davis


More information about the Digitalmars-d mailing list