<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 July 2015 at 10:33, Johannes Pfau via D.gnu <span dir="ltr"><<a href="mailto:d.gnu@puremagic.com" target="_blank">d.gnu@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Sat, 11 Jul 2015 13:37:42 +0200<br>
<span class="">schrieb "Iain Buclaw via D.gnu" <<a href="mailto:d.gnu@puremagic.com">d.gnu@puremagic.com</a>>:<br>
<br>
</span><span class="">> On 11 July 2015 at 10:01, Johannes Pfau via D.gnu<br>
> <<a href="mailto:d.gnu@puremagic.com">d.gnu@puremagic.com</a>> wrote:<br>
><br>
> ><br>
</span><span class="">> > Isn't the frontend version usually more important for the user? The<br>
> > frontend version determines if user code compiles or not and the<br>
> > frontend version is used to compare compilers. The GCC version has<br>
> > very little effect for users. This way if users are looking for a<br>
> > specific frontend version they'll have to walk all the gcc version<br>
> > folders.<br>
> ><br>
> ><br>
</span><span class="">> For us, it's toolchain that is more important. The GCC version does<br>
> affect users, but in more subtle ways. For instance, a new<br>
> optimisation pass may corrupt programs, or if they get a version of<br>
> gdc built against gcc-5.1 and debug a program on Ubuntu 12.04LTS,<br>
> that gdb won't really work very well at all. The overall experience<br>
> is much better if you install the correct version that works with<br>
> your running system.<br>
><br>
<br>
</span>OK. OTOH this suggests we should also build new frontend releases for<br>
older GCC versions for these users? But this would probably eat quite<br>
some disk space.<br>
<div><div class="h5"><br></div></div></blockquote><div><br><br></div><div>Shouldn't be too much, currently there is not a high frequency of frontend updates (once every 8 or so months), and there are typically 2 minor GCC releases a year for a particular version. I think it's good as a general rule of thumb to only update/maintain the D frontend for the last three GCC releases.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5">
><br>
><br>
> > > eg:<br>
> > ><br>
> > > /binaries<br>
> > > |- 4.8.4<br>
> > > | |- x86_64-linux-gnu<br>
> > > | | |- gdc-4.8.4+2.061.2.tar.xz<br>
> > > | | |- gdc-4.8.4+2.062.tar.xz<br>
> > > | | |- gdc-4.8.4-arm-linux-gnueabi+2.061.2.tar.xz<br>
> > > | | |- gdc-4.8.4-arm-linux-gnueabi+2.062.tar.xz<br>
> > > | | |- gdc-4.8.4-x86_64-w64-mingw32+2.061.2.tar.xz<br>
> > > | | |- gdc-4.8.4-x86_64-w64-mingw32+2.062.tar.xz<br>
> > > | |- arm-linux-gnueabi<br>
> > > | | |- gdc-4.8.4+2.061.2.tar.xz<br>
> > > | | |- gdc-4.8.4+2.062.tar.xz<br>
> > > | |- x86_64-w64-mingw32<br>
> > > | | |- gdc-4.8.4+2.061.2.tar.xz<br>
> > > | | |- gdc-4.8.4+2.062.tar.xz<br>
> > > |- 4.9.2<br>
> > > | |- arm-linux-gnueabi<br>
> > > | |- x86_64-linux-gnu<br>
> > > | |- x86_64-w64-mingw32<br>
> > > |- 5.1.0<br>
> > > | |- arm-linux-gnueabi<br>
> > > | |- x86_64-linux-gnu<br>
> > > | |- x86_64-w64-mingw32<br>
> > ><br>
> > ><br>
> > > I want to avoid a situation where there is both<br>
> > > gdc-4.8.2-2.061.2-20140430 and gdc-4.8.2-2.061.2-20150430 in the<br>
> > > same directory. We are already overcrowding the name with a<br>
> > > version number pair, adding in a timestamp just makes it<br>
> > > unreadable.<br>
> > ><br>
> > > So, rather than having timestamps, I think we should just<br>
> > > co-ordinate our binary releases around GCC major and minor<br>
> > > updates.<br>
> ><br>
> > And frontend releases? If the dmd team really implements a 2-month<br>
> > release schedule we'd miss some frontend versions otherwise.<br>
> ><br>
> > > My<br>
> > > preference being, if we really must push in an update tarball<br>
> > > whose GCC/DMD version pair is already on our FTP server, I'd<br>
> > > rather just overwrite the previous version, maybe moving the<br>
> > > original into an old-releases directory.<br>
> ><br>
> > We can probably avoid the timestamp and git revision. We shouldn't<br>
> > overwrite files though: users might check checksums for downloads<br>
> > or do URL-based caching. I'd add a counter for further releases at<br>
> > the end instead:<br>
> ><br>
> > gdc-4.8.4-x86_64-w64-mingw32+2.062.tar.xz<br>
> > gdc-4.8.4-x86_64-w64-mingw32+2.062_r2.tar.xz<br>
> > gdc-4.8.4-x86_64-w64-mingw32+2.062_r3.tar.xz<br>
> ><br>
> ><br>
</div></div><span class="">> I still feel that we should avoid imposing a three layer versioning<br>
> system. Either build a new tarball after each GCC major/minor<br>
> release, or a new tarball when we update to the next D version (and<br>
> it has matured for a bit).<br>
<br>
</span>Sure. I just meant that if we have to provide new releases for some<br>
reason (like if a toolchain doesn't work at all cause we forgot to<br>
install some files or similar cases) we should never simply override<br>
releases. But normally we should ship only one release without counter.<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">If the toolchain is broken or files are missing, I'd much rather remove the broken tarballs if we discover such problems quickly (ie: within a week or two). Otherwise it's delay until next GCC/DMD release. If upstream DMD actually commit to a bi-monthly schedule, this probably won't be so bad. It would mean that there are 7/8 releases a year per GCC version.<br><br></div><div class="gmail_extra">Think in the order of:<br><br></div><div class="gmail_extra">gcc-5.1+2.068<br></div><div class="gmail_extra">gcc-5.1+2.069<br></div><div class="gmail_extra">gcc-5.1+2.070<br>gcc-5.2+2.070<br></div><div class="gmail_extra">gcc-5.2+2.071<br>gcc-5.2+2.072<br>gcc-5.2+2.073<br>gcc-5.3+2.073<br><br></div><div class="gmail_extra">However I hope that people don't get comfortable with this kind of high maintenance. If we were part of mainline GCC, I'd expect that we won't have the opportunity to do a major frontend update once a release goes out (example, Ubuntu 14.04LTS has GDC with 2.064.2, and this will continue to be supported until 2020†), point releases would be OK though.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">† I had given forewarning of this, but no one actually considered maintaining 2.064 support in their projects. <a href="http://forum.dlang.org/post/lif4uj$2qt7$2@digitalmars.com">http://forum.dlang.org/post/lif4uj$2qt7$2@digitalmars.com</a> (It would be nice if the core library maintainers gave this consideration though before breaking ABI)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards<br></div><div class="gmail_extra">Iain<br></div><div class="gmail_extra"><br></div></div>