> And, I suppose, v3 will remain either CVS-only or, if > available for direct download, clearly marked as unstable > development version. Then, I stop considering it for > inclusion in the tutorial for now.
Rob will correct any mischaracterizations, but I don't think that's the right way to look at the two branches. WiX 2.0 is basically "done" -- if it were a commercial product, we'd have sent the bits for CD mastering and already bought the beer for the ship party.<g> The only changes that should be happening in WiX 2.0 now are bug fixes. New features aren't appropriate, because almost any feature work has a chance of destablizing the code. WiX 3.0 is where active development is happening. That doesn't mean it's unstable, just that it hasn't yet gone through the long baking period that WiX 2.0 has. It's new, it hasn't proven itself yet. And there are no promises that your WiX sources and build scripts will work throughout the 3.0 series. Now, the loc work for WixUI is isolated from the core tools. (In fact, the original loc work relied on a WiX 3.0 feature, but Derek suggested backing off from it.) But the build change to add a -loc switch is a breaking change, so it's not something we want to force on users without talking about it first -- because it breaks the rules about 2.0 stability. > But let's go back to the -loc switch for a minute. I have to > ask because I don't know the internal details and it's easier > to ask you than to start to find out for myself. Yes, v3 will > have the strings embedded but overridable. But is there > something that would make it impossible to equip the linker > with a default mechanism? If it can't resolve a string and it > has no -loc file specified by the user, it would first > include a -loc English.wxl itself and try to resolve again. > If it fails, it gives an error message. If the user has > specified a -loc, it wouldn't try to include English.wxl > itself. Is this impossible within the current way of doing things? It's not a trivial change, I'd say. There's also a "code smell" about hard-coding the name of the .wxl file. And which directory would the linker look in for it? More important, though, is that it's a change that might destabilize current localization support. It might even touch other parts of the linker too. That's probably not appropriate in an "extremely stable" branch. So that's my two cents on the issue. If we're going to make a change, I'd rather it be the simplest change possible. > * I use the complete UIsample stuff, with the administrative > dialogs included. As far as I can tell from the source, those > are not yet in WixUI. These, plus the localization (which I'm > willing to contribute for my language, of course) is what I'd > expect. What's the roadmap? Is this to be expected as things > are now or are helping hands required to reach this level? Admin dialogs are on my list, but fairly low. sig://boB http://bobs.org ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
