On 12 July 2015 at 10:33, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> Am Sat, 11 Jul 2015 13:37:42 +0200 > schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>: > > > On 11 July 2015 at 10:01, Johannes Pfau via D.gnu > > <d.gnu@puremagic.com> wrote: > > > > > > > > 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. > > > > > > > > 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. > > > > OK. OTOH this suggests we should also build new frontend releases for > older GCC versions for these users? But this would probably eat quite > some disk space. > > 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. > > > > > > > > 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 > > > > > > > > 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). > > Sure. I just meant that if we have to provide new releases for some > reason (like if a toolchain doesn't work at all cause we forgot to > install some files or similar cases) we should never simply override > releases. But normally we should ship only one release without counter. > > 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. Think in the order of: gcc-5.1+2.068 gcc-5.1+2.069 gcc-5.1+2.070 gcc-5.2+2.070 gcc-5.2+2.071 gcc-5.2+2.072 gcc-5.2+2.073 gcc-5.3+2.073 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. † I had given forewarning of this, but no one actually considered maintaining 2.064 support in their projects. http://forum.dlang.org/post/lif4uj$2qt7$2...@digitalmars.com (It would be nice if the core library maintainers gave this consideration though before breaking ABI) Regards Iain
