Restructuring the download archive

[Iain Buclaw via D.gnu]

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

> Am Sat, 11 Jul 2015 13:37:42 +0200
> schrieb "Iain Buclaw via D.gnu" <d.gnu at puremagic.com>:
>
> > On 11 July 2015 at 10:01, Johannes Pfau via D.gnu
> > <d.gnu at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20150712/9639b091/attachment.html>