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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
