On 10 July 2015 at 14:45, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:

I thinks it's time to push some new binary releases to gdcproject.org (gcc-5, intrinsics for checkedint, ...). We should first get some structure into our download archive though: ftp://ftp.gdcproject.org/binaries/

The first question is whether we can break old download links. I've hardcoded one or two toolchain URLs in the build scripts, but that could be changed easily.

I think we can break anything that isn't a short name (should be a symlink on the server). We need to keep at least these for Travis to continue working.

http://ftp.digitalmars.com/LATEST_GDC

By all means, we can raise a PR with Travis to move it elsewhere, then remove the rest of the old structure later.

Another question is how exactly the new directory layout should look like. I think we definitely need host folders as a top-level structure:

/binaries
|- x86_64-linux-gnu
|- x86_64-w64-mingw32
|- arm-linux-gnueabi

Do we want to have the target as a directory? GCC version? Frontend version?
I think the frontend version is usually more important for users than gcc version. So if we don't use the GCC version we still have two options. dmdversion/target or target/dmdversion:

/binaries
|- x86_64-linux-gnu
| |- 2.061
| | |- x86_64-w64-mingw32
| | | |- x86_64-w64-mingw32_2.061.2_gcc4.8.2_AAAA_20140430.tar.xz
| | | |- x86_64-w64-mingw32_2.061.2_gcc4.8.2_BBBB_20140430.tar.xz
| | |- arm-linux-gnueabi
| |- 2.062
|- x86_64-w64-mingw32
|- arm-linux-gnueabi

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.

eg:

/binaries

|- 4.8.4

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. 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.

Regards

Iain