Rant: So you want help?
thomas.friedrichsmeier at ruhr-uni-bochum.de
Sat Nov 6 18:00:03 CET 2010
On Saturday 06 November 2010, Andrius da Costa Ribas wrote:
> We CAN'T break up the installer.
I wasn't going to pursue this idea any further for the moment, but - come on.
As long as we can't have multiple compilers inside *one* installation, there's
no terribly strong point for having multiple compilers inside *one* installer.
Breaking up the installer or not is pretty much orthogonal to the question
which compilers are supported.
Ok, again, I'm not going to pursue this for the moment. Quite obviously the
disucssion is not going anywhere, so I'll try to make progress some other way.
> 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.
Well, I don't know how you do that already. I'm very much looking forward to
But in fact, I am suggesting to allow more indepence that is currently
possible. Yes, ideally, all compilers will release within in a very short time
frame. But I'm trying to make sure that this is not a mandatory requirement
for releasing anything at all.
Right now one central problem with having a time gap between the compilers is
that it will cause serious confusion. Suppose MSVC is at 4.5.3, while MinGW is
still at 4.4.4. Right now, users will
1. select a mirror
2. select a compiler (let's suppose user choses MinGW, here)
3. select a release (obviously user selects the latest one, i.e. 4.5.3)
4. select packages (but our example user will not see *any* packages, since
there are no MinGW 4.5.3 packages)
What I am suggesting is that users will
3. select a release _type_ (stable / unstable / nightly)
4. MinGW users will be able to select 4.4.4 packages, MSVC users will see
To me this sounds quite doable, with minimal changes in the installer, and the
directory layout on the server. So does it sound like something that you can
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20101106/346e4770/attachment.sig
More information about the Kde-windows