<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 July 2015 at 10:01, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Fri, 10 Jul 2015 16:26:35 +0200<br>
schrieb "Iain Buclaw via D.gnu" <<a href="mailto:d.gnu@puremagic.com">d.gnu@puremagic.com</a>>:<br>
<span class=""><br>
> > Another question: DMD frontend sub-releases in one folder?<br>
> > (2.061|2.061.1|2.061.2)<br>
> ><br>
> ><br>
</span><span class="">> I think GCC releases should take precedence over D Frontend and<br>
> architecture IMO.  As that is the most recognisable (and important)<br>
> aspect of the name.<br>
><br>
<br>
</span>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 very<br>
little effect for users. This way if users are looking for a specific<br>
frontend version they'll have to walk all the gcc version folders.<br>
<span class=""><br></span></blockquote><div><br></div><div>For us, it's toolchain that is more important. The GCC version does affect users, but in more subtle ways.  For instance, a new optimisation pass may corrupt programs, or if they get a version of gdc built against gcc-5.1 and debug a program on Ubuntu 12.04LTS, that gdb won't really work very well at all.  The overall experience is much better if you install the correct version that works with your running system.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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>
</span>>  |  |- 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>
<span class="">>  |  |- 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 same<br>
> directory.  We are already overcrowding the name with a version<br>
> number pair, adding in a timestamp just makes it unreadable.<br>
><br>
> So, rather than having timestamps, I think we should just co-ordinate<br>
> our binary releases around GCC major and minor updates.<br>
<br>
</span>And frontend releases? If the dmd team really implements a 2-month<br>
release schedule we'd miss some frontend versions otherwise.<br>
<span class=""><br>
>  My<br>
> preference being, if we really must push in an update tarball whose<br>
> GCC/DMD version pair is already on our FTP server, I'd rather just<br>
> overwrite the previous version, maybe moving the original into an<br>
> old-releases directory.<br>
<br>
</span>We can probably avoid the timestamp and git revision. We shouldn't<br>
overwrite files though: users might check checksums for downloads or do<br>
URL-based caching. I'd add a counter for further releases at the end<br>
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></blockquote></div><br></div><div class="gmail_extra">I still feel that we should avoid imposing a three layer versioning system.  Either build a new tarball after each GCC major/minor release, or a new tarball when we update to the next D version (and it has matured for a bit).<br><br></div><div class="gmail_extra">Iain.<br></div><div class="gmail_extra"><br></div></div>