Batch update .wyp files?

IIRC, you mentioned that making wyp a binary format was an oversight / unfortunate early choice - any progress on making it an XML or other text-based format?

We're not making that change for the upcoming 2.8. Maybe later. Probably we'll just make it easier to build projects from commandline.

Amending changes to the WYP file via XML as described in http://wyday.com/wybuild/help/commandline.phpis very powerful and good enough for me.

BTW, is it possible to modify the update servers via XML ?

BTW, is it possible to modify the update servers via XML ?

No, you have to open the project to do that. We figured it was a rare enough operation that it shouldn't be included in the options for commandline modification.

If you're changing sites frequently you might consider using -server or -updatepath.

For me, we really could use a command line way to say "Create a new wybuild project with the following parameters..."

The command line scripting does everything I need *except* the ability to create the initial project correctly.

I use a batch script currently that copies a dummy template project out to a new location to start a new update series (starting from this, and then adding deltas in the future), and it detects the existence of a given sequence, and then uses the xml to create a new version to append to the sequence.

For the most part - that works well. But the missing ability to generate the wybuild project from scratch, or alternately to use a command line "new key" is a big hole. It was not too bad in the beginning, but years on it is becoming a much bigger hole in how things work here (or to put it another way, it's a security hole that grows over time). Without the ability to do this from a script, I either have to have a human manually do this stuff (very, very error-prone), or I have to live with a security hole. We chose the security hole thinking this will be addressed sooner than later.

it's not the end of the world security hole, but it seems silly given that the missing bits are quite small (reset the security key for a project, or allow a project to be created from an xml like deltas are).

It's a great product, and serves its purpose damn well. Just don't want to have our needs - which seem pretty basic and straight-forward - to be blown off as "doesn't know what he/she is doing." I do. The limitation is wyBuild/wyUpdate. It's unavoidable without the ability to hack a project file - which is impossible due to the binary nature of it. Should have been a text format!

Hope to see this addressed, but can live for a while longer without it.

NOTE: also, the binary project file means you can never ever change your folder structure or file locations for a given update series. This is not painful at first - but try restructuring your file servers or build process and tell me this isn't a gaping hole! If the wybuild project was a text format, then the existing encoded paths could be fixed with SED or something similar. As is, one must either never change folder structures on the wybuild universe, or break the series and introduce a discontiguous gap to a new update series (that you somehow deliver to your customers by some other means, since wybuild projects are all broken and can't generate this update).

It's a great product, and serves its purpose damn well. Just don't want to have our needs - which seem pretty basic and straight-forward - to be blown off as "doesn't know what he/she is doing."

We're not blowing you off. We plan to make the wyBuild project format XML based, but it's just not an immediate priority.

For the most part - that works well. But the missing ability to generate the wybuild project from scratch, or alternately to use a command line "new key" is a big hole.

You mean the update-signing key-pair?

NOTE: also, the binary project file means you can never ever change your folder structure or file locations for a given update series.

wyBuild has used relative file paths for some time. So if the project file is on the same harddrive (or, same drive letter -- e.g. "C:\") as your files, then relative paths will be used. This means you can move the project and the files together to any other folder and the project will still reference the relative files.

Does that make sense?

Thanks for the responses.

Yes, I mean the signing-key part - as I understand it, that is what wyUpdate checks to see if the update is a valid package for the current application. If it has the wrong key, then it's not appropriate to this installation, and rejects it. Not the biggest deal, but it helps us ensure that the right update is applied to the correct software (really, avoids users cheating but constructing their own wyUpdate command line and spoofing the system). Small issue overall.

I know that the files are relative - but I've moved the files to a new root location. The files are internally still the same (i.e. version 15.0 and 15.1 - if taken as the root, all of the files under those locations are relatively the same - but where 15.0 and 15.1 are located has changed - and wyUpdate wants them to still be located at the same base location, as far as I can tell (the error message was along the lines of file-not found).

e.g. Used to be:

\\build-server\media\english\15.0\...\\build-server\media\english\15.1\...

now

\\file-server\install\public\english\15.2\...

So the root-paths have changed, but the files within each version are relatively the same, and 15.2 and 15.1 are based in the same location....

Not the end of the world for us, since we create a new sequence for every major release (wyupdate is for updates within a given release, rather than from one paid version to the next). So having new this break is okay for us, as we're starting a new update-series anyway. Still - worrisome to have such fragility baked in (or so it appeared in my limited testing). Perhaps my testing was too limited, and I jumped to conclusions on this? If so, my apologies.