Restructuring the download archive

[Johannes Pfau via D.gnu]

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.

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