I imagine that this particular aspect has the potential (maybe unavoidably so) to bloom into a complex and time consuming piece.
I hate to sound any notes of concern, but that's what my gut tells me. E.g., my own description indicating that the .wyp must have access to all of the optional modules... is going to be problematical from our standpoint. It would be better if we could add the optional modules later, even for an existing version (i.e. they could be defined up-front [or not], but the modules themselves (in our case: translations) may not be available until sometime after the main components have been released for a given version).
Let me try to give you a concrete scenario, so it's not so hard to parse:
We build a version - say 1.1. This version initially is released in north America, in English only. Over the next few weeks, the Japanese and Spanish translations for 1.1 arrive. They're built. Now I can either have separate tracks (1.1 Japanese, 1.1 Spanish, and 1.1 English), or I could have a single track with three optional modules (1.1 core, 1.1 English-module, 1.1. Spanish-module, 1.1 Japanese-module).
From a hard drive space perspective, having it modularized makes the most sense.
From a work-flow perspective, I'm not sure how wyBuild's .wyp will be able to best handle the realities of optional modules being available later than the initial release (containing only a single optional: English). I can see manipulating the .wyp so that the extra optionals are added later, or better, having the .wyp know about the other optionals (as potentials) but not error if they don't exist at build time, with some easy-to-use ability to build the optionals later (or just rebuild the project at a later time).
Fundamentally, the issue is fairly trivial from the perspective of what actually is placed on the server, and how the client side need handle it. That side seems simple to me: it always updates the core and any client-side-existing optionals. The only possible gotcha is that it shouldn't update at all unless all of its optionals are available for that update delta (can't have the core updated but English unable to update; that wouldn't work for our software for certain).
Sorry to confuse the issue... but I'm sure you can see that just from our relatively simple (well organized) system of modules, quite a few questions arise, and flexibility is going to be required on the build side, while some of the rules need to be ironed out on the client side (i.e. for some customers updating the core might be fine even though some of the optionals aren't available for that delta yet; as opposed to ours where we would want them to be in lock-step from the client's perspective, but not from the server's perspective).
We can happily work with your tools w/o optional-module support. Using a separate update-track per language combo actually fits our workflow very well. It uses more disk space, for certain, but the above complexities disappear. So this is not holding us up, and we'd rather see a fairly well-thought-out and flexible system later than something that doesn't quite handle the complexities now.
Thanks again for your willingness to listen / think!
