Restructuring the download archive

[Johannes Pfau via D.gnu]

Am Fri, 10 Jul 2015 16:26:35 +0200
schrieb "Iain Buclaw via D.gnu" <d.gnu at 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________   |
|                                     |
---------------------------------------