Correct, if only a single version exists then the only update will be the "catch all" update. Add another version and the only update will be the delta patches.
-catchall="false"
Doesn't seem to work... but maybe this setting is ignored for the first build - i.e. when there is no other delta?
I've tried -catchall=false and -catchall="false", but both still produce the all update.
Okay... but then what is the point of having that generated?
If I have the first release that includes wyUpdate (let's say that's 1.0). That version cannot update yet - there is nothing new yet, and there are no prior versions that can take advantage of this update-all file...
When I release 1.1, then it will generate a delta to 1.0, and that is the first version that anything in the universe can use (1.0 -> 1.1). If there is a bad install, then presumably it would need the all-to-1.1, not all-to-1.0, no?
Sorry for the confusion, still trying to figure out the details 🙂
----
Basically, this ties into the walk-through: in there we're asked to generate the first version without adding any files to it, for the "1.0" type release. In 1.1 we add the app's files (and am I to understand we also retro-add the files for 1.0 in order to generate a valid delta for 1.1?). I assume that all versions within a .wyp need to know the location of their files (and be non-empty) in order to generate a valid delta for the next version?
So I guess I'm back to confused about the usefulness of all-to-1.0?
In the step-by-step walkthrough we say to not add any files to the first version (initially) for the very reason that the update files generated is useless. That is, why generate a huge file if it's never used? But later in the walkthrough we say to add the files to the first version so that patches from this version (to a newer version) can be made.
So the question is: why generate an "all.to.X.X.wyu" file for the first version when it will never be used? The answer is that we don't know that the "X.X" version is the first version. It could be a user creating large "whole file" updates for their app (instead of going the patch route).
Does this make sense?
Yes - thanks for the clarification.
So my post becomes: Can I Haz Override to make "-cathcall=false" stick? I really don't want it for the first build, since I really do need (from a scripting perspective) to have the 1.0 include the correct files (so that 1.1 will create the right delta), but I don't want 1.0 to really produce anything but an empty shell of an update (i.e. as though I had not added any files yet for 1.0).
EDIT: i.e. I need to emulate the sequence (or outcome) that you have us do in the walk-through, which, is very difficult from a scripting perspective currently (I would have to keep track of which version was second in each case: first is trivial, second requires maintaining .ini files and logic for my scripts - which is a PITA).
Having -catchall=false generate an empty update when there would otherwise be no other files to generate would do the trick. Or another command-line option to explicitly ask for this outcome.
(EDIT2: Deleted: turns out if I keep track of which build is 2nd, I can already do this)
Does that make sense?
From a scripting perspective you'll have code that creates the initial project using the soon-to-exist feature you requested. This is the time you would create the empty version. Here's what I imagine it would look like:
- Script creates a new wyBuild project with an existing version number.
- Build wyUpdate for your first version & build updates for this version.
- Upload the "blank" updates
- Overwrite the existing version using <AddVersion overwrite="true">....</AddVersion>
Then, your regular release script will be unchanged.
Yes. Thanks!