Restructuring the download archive

[Iain Buclaw via D.gnu]

On 11 July 2015 at 10:01, Johannes Pfau via D.gnu <d.gnu at puremagic.com>
wrote:

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



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

Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20150711/94120174/attachment.html>