What is a nightly build ?

A nightly build is a build that reflects the current state of the source code checked into the source code version control system by the developers. These builds are mostly for testing purposes and can be unstable, but some issues that existed in the previous stable versions of MPC-HC might have been fixed here.

Download MPC-HC nightly builds

Nightly builds for MPC-HC can be found at:

Official nightly builds

These are the only supported builds because the developers can debug those builds and the building environment is trusted.

How to help fixing regressions using the nightly builds

When a new revision breaks something which was working in previous revisions, the bug is called a software regression. A way to help fixing those bugs is to narrow down as much as possible the range of revisions where the regression was introduced and this can be done using the nightly builds.

For example, let's imagine that you have found a bug in revision 200 but you know revision 100 was working correctly then the bug you found is a regression. However if you only tell us that the regression was introduced between revision 100 and 200, it will be quite difficult for us to find which of the 100 revisions in the range is the culprit.

A naive way to narrow down the range of revisions would be to test all nightly builds in this range to find the last working revision and the first non-working revision. This approach will work but can take you a lot of time. A more efficient way is to use a binary search.

The main idea of binary search is to test the revision which is in the middle of the range where the bug was introduced (or at least the closest nightly build you can find). For example for the range 100-200, you should first test the revision 150. If this revision works correctly, the new range would be 150-200 and if it does not, the new range would be 100-150. As you can see, in both cases the range's length was divided by two.
By repeating the same procedure on the new range, you will be able to find the last working revision and the first non-working revision but much more rapidly than using the naive approach.

Last modified 4 years ago Last modified on 2016-01-12T16:31:54+01:00