On 27-03-2010 19:37, Adrian Buehlmann wrote: > On 27.03.2010 18:54, Sune Foldager wrote: >> Hey :) >> Maybe I'll have more success explaining this in an email, so here goes. > > I tried as well on IRC, but I asked you *twice* to wait a bit to no > avail, as I am way slower at typing than you. I decided to leave IRC, as > your messages were piling on my end, without the slightest chance by me > to respond.
Well, I didn't understand it as 'wait a bit with typing', but ok; and you did quit without stating a reason. > Correct. And they are not needed to stay persistent. The only thing that > is expected to stay persistent is the product upgrade code. > > See my other email to this list. See my other reply to that email. You keep missing that I several times said IF we were to do component-wise updates (minor). >> Now, it's my understanding that IF we were to use the same product guid >> for each release (and not just the same upgrade code), then MSI would be >> able to do a by-component upgrade of the installation. > > No. Minor upgrades don't work anyway with the current design of the WiX > sources. And I'm not going to try to make them minor-upgrade safe. I said IF we were. Also: >> I realize this is >> not presently the case. >> a) My understanding (above) is incorrect. If so, please enlighten me :) >> b) IF we were to switch to using same-product-code, we wouldn't be able >> to correctly upgrade the components. >> c) Same as b except: ..we wouldn't be able to take full advantage of the >> feature. > > We can't anyway. For other reasons that are beyond the scope of such a > thread here. Who are you to define the scope of threads? This is a development mailing list, and I'm a contributor. Where ARE these things in scope, then? >> d) The GUIDs are not used, or not used in this way. If anyone knows, >> please share :) > > Some are already used on unstable. Please look into the recent changes > of the shell extension for unstable. By use I mean 'used by MSI', which they presently aren't (well, in any persistant sense). If we did minor, they would have been. > But I'm going to move the GUID definitions out of the C++ sources (build > params). af2543f5be87 is just a start for something I'm planning to do, > as soon as I get to it. Sounds good. >> If b or c, I recomend we switch back to static entries for that >> particular foreach, or find another way to keep the GUIDs persistant. > > No. Trying to do minor upgrades is a wet dream anyway. See my other email. Well, I *did* have that recomendation. And see my other reply also. > In that particular case (locale and translation files), having > non-persistent component GUIDs is fine. > > The design decisions have been made. The installer is not "minor > upgrade" capable anyway. Not just for the "*" component GUID I've > inserted for the locale and translation files. Ah, I didn't know this was a solo project where things are beyond discussion... /Sune ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
