Rant: So you want help?

[Thomas Friedrichsmeier]

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

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

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 
agree with?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20101106/346e4770/attachment.sig