More command-line options desired! ;)

The addition of the -add "xxx.xml" is great! The options there are perfect for our needs inasfar as creating a new version to a .wyp sequence is concerned.

However, I'm having to revert to manual intervention for setting a .wyp's other values, which could easily all come from our build scripts.

e.g. I can manually create a prototype .wyp for each of our products, e.g. PRODUCT1.wyp.

In there I can specify the product name and company, languages, theme.However, I really need to be able to specify the: Download Sites and Upload Sites!

Presumably, the Download Sites needs to have a path that is specific to this product (vs. our other products), and similarly, the Upload needs to correspond to just this product - in fact, it needs to exactly correspond to Download sites, no?

, edited

As of wyBuild 2.6.x you have to manually create the intital project file. Is there a reason you want to automate this?

Yes: accuracy, maintenance, and ease of use.

We have 4 main products, plus a handful of minor ones, each main product is updated in unison, so 4 product builds per build cycle.

I'm going to need to keep the upload/download folder unique for each major product's version-series.

My build scripts know everything needed to produce exactly this information. They could happily work with an existing template .wyp file, and just modify the upload/download data each time a new series is started for each product (and minor product).

Without automating this via scripts, I'm going to have to force the build-operator to intervene manually, and create 4 .wyp projects at the start of each new series, plus an additional .wyp for each minor project at the first build of each new series.

This is not rocket science, but it means I'm introducing human error: my script would get the upload/download correct every time. But a human has to know to go to a place, change it thusly, go to another place, change it similarly but not the same, etc. Needless to say, on the best days, they'll know what they're doing but may make simple errors (such as mistyping the FTP upload site or password, etc.), and on the worst of days, they'll have forgotten most everything related to this process because it's been 6 months since they last had to do this, not know what to do with the.wyp file, not sure where to get the FTP info needed, not know what pattern to follow to know how to change the template to be correct for each product, etc.

So, automation encapsulates this process neatly, documents what it's doing in the scripts, is correct every time, and saves the human being from having to get sidetracked by these requirements, allowing them to stay focused on the work at hand instead of the details.

EDIT: If the .wyp files were stored as .xml or some similarly text-editable format, then I could use sed or something similar to modify a template as needed.

OK, we'll let you automate the creation of projects in the next version of wyBuild (2.6.15 or 2.6.16).

EDIT: If the .wyp files were stored as .xml or some similarly text-editable format, then I could use sed or something similar to modify a template as needed.

In retrospect, we probably should have chosen an XML format over our binary format.

One more thing to think about with your developers / designers:

I would like to take advantage of wyBuild during our beta process. This would extend both internally, and with our external beta testers. This sounds eminently doable with your software, so long as I separate this update-series from the regular release updates.

i.e. 1.0.0.1 through 1.0.0.9999 would be betas. Then when we release, I'd start a new series, from 1.0 (the release version). Since its a separate series, separate base .wyp & location on our server, there would be no confusion, and retail installs would be isolated from betas (this does mean that for beta customers they'd be required to do a regular install to get from the beta to the retail - but that's very acceptable).

My point in bringing this up: that's a whole additional set of series per product per cycle - and yet more solid reason why .wyp files should be automatable - at the very least to the extent that I can set their download site data from the command line when creating the first .wyp in a given series. I can get around needing to set the upload site, because I can to the upload from a scriptable 3rd party utility. But I can think of no way around needing to set the download site for a .wyp - can you?

i.e. 1.0.0.1 through 1.0.0.9999 would be betas. Then when we release, I'd start a new series, from 1.0 (the release version). Since its a separate series, separate base .wyp & location on our server, there would be no confusion, and retail installs would be isolated from betas (this does mean that for beta customers they'd be required to do a regular install to get from the beta to the retail - but that's very acceptable).

This is a separate problem we're trying to solve with wyBuild 2.8 -- update channels. That is, your product can have different channels for different version branches and the ability to switch between them on the client side.

But yes, we'll add the ability to automate the creation of project files. You've convinced us.

But yes, we'll add the ability to automate the creation of project files. You've convinced us.

Woot!

Thanks! I'm looking forward to keeping our clients much more up to date, and making the next beta cycle much faster at fix & release. 🙂

Sam - sorry to dig up an old thread, but I figured context might be useful...

We've been using your product for over a year now, and it's been a great asset. Many of our customers have given us positive feedback on their experience of using it - and it has made beta testing cycles much more productive (especially for the users, who get fixes much more rapidly). So THANK YOU! 👽

I've put off updating my scripts until now due to time constraints, but I'm finally in the clear for our up-coming major new version. I would like to fix our scripts to take advantage of all of the goodies you've included in .16/.17.

The first, and probably most important, is "How do I create a new .wyp from scratch?"

http://wyday.com/wybuild/help/commandline.phpcovers how to add another version to an existing .wyp. And I've been using that successfully for a year now.

But I don't see how to create a new .wyp from scratch. Or alternately, how to set the download location for an existing .wyp via command-line / add xml template? 🤓

But I don't see how to create a new .wyp from scratch. Or alternately, how to set the download location for an existing .wyp via command-line / add xml template?

We haven't yet added it. You can certainly modify the binary format of the *.wyp files, but we haven't made a simple XML interface yet.

Ah, that explains it. I thought i saw something in the update lists... but obviously I was mistaken.

Not a big deal, thanks

+1 for this request to be able to create *.wyp files from the command line.

I see that this post discussed a beta process, and we have something similar here - our game is almost 1.5GB and this means that very quickly, within a week of an daily build process, the whole thing comes to a crawl and we have to start over - we have scripts to start over but the manual step first is to remove all old versions from the wyp project(s) manually (a process itself which is very slow since wybuild seems to struggle with these large projects).

Obviously by removing these old versions, we lose support for updating old versions but we always create a full installer of the latest build on a Monday morning (when we remove all of the old versions). Our automated test system uses these updates too and they literally always only ever need support for a few different versions (depending on what stage they are at), so really I would probably prefer if we could get a list of the versions from the command line somehow, so we can iterate and remove those which we no longer need. At the moment this means one person is losing a couple of ours every week having to do this manual process which ideally would be a trivial automation job.

so really I would probably prefer if we could get a list of the versions from the command line somehow, so we can iterate and remove those which we no longer need.

If you're automating the addition of versions, then why can't you store in a file somewhere the versions you added to the project. Then, when you want to remove those version, read the file of versions you added, tell wyBuild to remove those versions, and everything is fine.

Does that make sense?

Yes, perfectly. How can I remove versions from wybuild in the command line? I can't see it documented - we have "-add", but not "-remove". That is what I am asking for, really.

Ah, brillant. Thank you!

Just wanted to say "Still looking for the ability to create a wyp from the command line".

Our current process copies a template .wyp, then copies the correct upload path to the clipboard, launches wybuild on the new .wyp, and tells the user to paste the data into the appropriate field, and to save that file. The script waits for the user to return and verify that they completed this successfully.

This is quite clumsy. I would much prefer to be able to do the above via the script entirely. Any chance that this has moved forward and I'm just not aware of it?

Not yet.