On 11 August 2015 at 13:05, Martin Nowak via dmd-internals <dmd-internals@puremagic.com> wrote:
On 08/10/2015 07:10 PM, Iain Buclaw wrote:
> - Do we need to keep ddmd working with 2.068?
>
> For the time being, yes, and for as long as possible.

Sticking to an old version of the compiler defeats a major reason to
switch to self-hosting. By using D ourselves for a big project we'll
resolve particular issues that'll come up. But if we cannot profit from
solving those, this will have little impact.


IMO, it only enforces that we don't immediately jump onto using new features introduced post-2.068 within the compiler so quickly.

 
So what is the major reason we need backwards compatibility for more
than 1 version?
After all you can always do the following.

download2068
foreach (ver; 2.069 .. 2.085)
{
    git checkout ver
    buildWithPreviousVer
}


Because I operate around GCC releases, rather than DMD.  In the 6-8 months that a GCC development cycle and release is done, there could be many DMD releases during that time.  If (the nonexistent) GDC-6.2 built on 2.068 cannot build GDC-7.1 (2.072) or current GDC-8.0 development snapshot (2.075), then I have a serious problem with upstream development.

 
It seems to me the key problem is to guarantee that the above works,
which is what I meant with testing compatibility.
The minimum IMO would be the classical self-compiling check, and of
course a rigorous test suite.

buildWithPreviousVer
test
buildWithCurrentVer
test
buildWithCurrentVer <- binary must be equal to buildWithCurrentVer above
test


This cycle is what's done with GCC build process, if you change a few words around.

buildWithHostCompiler
bootstrap
buildWithBuildCompiler
bootstrap
buildWithBuildCompiler
Compare md5sum of second and third stage *.o files


Regards
Iain