Am Fri, 10 Jul 2015 16:26:35 +0200 schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
> > Another question: DMD frontend sub-releases in one folder? > > (2.061|2.061.1|2.061.2) > > > > > I think GCC releases should take precedence over D Frontend and > architecture IMO. As that is the most recognisable (and important) > aspect of the name. > Isn't the frontend version usually more important for the user? The frontend version determines if user code compiles or not and the frontend version is used to compare compilers. The GCC version has very little effect for users. This way if users are looking for a specific frontend version they'll have to walk all the gcc version folders. > eg: > > /binaries > |- 4.8.4 > | |- x86_64-linux-gnu > | | |- gdc-4.8.4+2.061.2.tar.xz > | | |- gdc-4.8.4+2.062.tar.xz > | | |- gdc-4.8.4-arm-linux-gnueabi+2.061.2.tar.xz > | | |- gdc-4.8.4-arm-linux-gnueabi+2.062.tar.xz > | | |- gdc-4.8.4-x86_64-w64-mingw32+2.061.2.tar.xz > | | |- gdc-4.8.4-x86_64-w64-mingw32+2.062.tar.xz > | |- arm-linux-gnueabi > | | |- gdc-4.8.4+2.061.2.tar.xz > | | |- gdc-4.8.4+2.062.tar.xz > | |- x86_64-w64-mingw32 > | | |- gdc-4.8.4+2.061.2.tar.xz > | | |- gdc-4.8.4+2.062.tar.xz > |- 4.9.2 > | |- arm-linux-gnueabi > | |- x86_64-linux-gnu > | |- x86_64-w64-mingw32 > |- 5.1.0 > | |- arm-linux-gnueabi > | |- x86_64-linux-gnu > | |- x86_64-w64-mingw32 > > > I want to avoid a situation where there is both > gdc-4.8.2-2.061.2-20140430 and gdc-4.8.2-2.061.2-20150430 in the same > directory. We are already overcrowding the name with a version > number pair, adding in a timestamp just makes it unreadable. > > So, rather than having timestamps, I think we should just co-ordinate > our binary releases around GCC major and minor updates. And frontend releases? If the dmd team really implements a 2-month release schedule we'd miss some frontend versions otherwise. > My > preference being, if we really must push in an update tarball whose > GCC/DMD version pair is already on our FTP server, I'd rather just > overwrite the previous version, maybe moving the original into an > old-releases directory. We can probably avoid the timestamp and git revision. We shouldn't overwrite files though: users might check checksums for downloads or do URL-based caching. I'd add a counter for further releases at the end instead: gdc-4.8.4-x86_64-w64-mingw32+2.062.tar.xz gdc-4.8.4-x86_64-w64-mingw32+2.062_r2.tar.xz gdc-4.8.4-x86_64-w64-mingw32+2.062_r3.tar.xz (The reason why I initially included both git-id and build date is this: If there's a problem with the build system we might need to rebuild the same revision of a toolchain. We than have a higher build count for one toolchain, but it's probably not a big issue). BTW: Maybe we can implement a download mask for older releases at some point: ______________________________________ | | | Host: ______________ | | Target: ______________ | | Frontend version: ______________ | | Release: LATEST________ | | | ---------------------------------------
