Rant: So you want help?

[Andrius da Costa Ribas]

We CAN'T break up the installer. Some things work only on MSVC (e.g.: WMI
backend for Solid) and some only on MinGW. It's a matter of personal taste,
period.
Releases for different compilers being independent is ok, but... don't we
already do that? At least we did it when we started supporting mingw on the
installer. As long as there is no big gap (2 weeks?) on releases for each
compiler sounds okay. Most of us use only one compiler. And most things that
are fixed for one compiler is also fixed for the other.


2010/11/6 Thomas Friedrichsmeier <thomas.friedrichsmeier at ruhr-uni-bochum.de>

> On Saturday 06 November 2010, Casper van Donderen wrote:
> > Everybody should take his compiler of choice
>
> Yes, and that's exactly the philosophy I'm trying to enable with respect to
> creating releases. Everybody take the compiler they care about, and only
> that
> one, instead of making releases artificially cumbersome by requiring to
> produce
> a complete set binaries for the complete set of compilers.
>
> > and maybe make the default
> > the platform default:
>
> To me, *personally*, GCC 32bit is the one hard requirement in the compiler
> department, because an external dependency of my application supports only
> MinGW on windows. And so that's why I'm willing to help with MinGW, and
> that's
> why I *personally* don't care about any other compiler.
>
> But you're right in that it's a dead-end to try to discuss one compiler
> against another, and I see we may be getting hung up on the side issue of
> which should be the default.
>
> So I'll modify my proposal for yet another short-term strategy (see also
> [1])
> to allow breaking up the release process into smaller portions:
> - Multi-compiler support will remain in the next version of the installer,
> but
> instead of working on point releases, the default choice of releases will
> be
> trimmed down to:
>  * stable-latest
>  * unstable-latest
>  * nightly-latest
> - These directories will differ from the current layout in that
> stable-latest
> may contain different versions of packages for different compilers. Perhaps
> at
> times MinGW will be a couple versions ahead, and perhaps sometimes MSVC
> will
> be some versions ahead. So once again, releases for the different compilers
> can
> be made independently of each other.
> - As long as there are no binary compatibility breakages (as coming up with
> KDE 4.6, AFAIK), this concept will even allow to create releases in a more
> incremental fashion, e.g. uploading an updated kdelibs, but leaving
> kdegames
> at its old version until a volunteer picks up that one.
> - Point releases will merely be archive snapshots, and will be completely
> hidden from the user (and perhaps even from the mirrors). Joe User only
> cares
> about the latest available stable/unstable/nightly releases, anyway.
>
> I think it's still a good idea to break up the installer into one
> incarnation
> for each compiler, and to decide on a default. But I'll leave that for
> another
> day.
>
> Regards
> Thomas
>
> [1] http://lists.kde.org/?l=kde-windows&m=128689460909832&w=2
>
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20101106/bf6ed6ed/attachment.htm