CodingGorillaI am working on using JetBrain's TeamCity to automatic post successful builds as updates using wyBuild. My question is, since TeamCity is getting my .wyp file from source control, and then generating a new version using an automated process that creates the "newversion.xml" file. The updated .wyp file, containing both the original version as well as the newly created version will be lost next time TeamCity does a succesful build and deployment.
Is it important to keep all of this versioning information?
So for example, my original .wyp project would have 1.0 in it. TeamCity would build and deploy 1.1, 1.2, 1.3, 1.4. At some point I add 2.0 to my .wyp project file and commit that to my source control again, and now TeamCity will have 1.0, 2.0, 2.1, etc. The versions which were posted (and presumably still exist on the deployment website) are lost. Is that a problem?
Is it important to keep all of this versioning information?
Yes, or else you'll have to readd all the old versions everytime you build a new update. wyBuild doesn't yet support "incremental patchs". Instead, what it does now, is "direct patches". That is, every version of your software has a direct patch to the latest version.
Short answer: save the modified wyBuild project file.
Does that make sense?
CodingGorillaLet me add this caveat: This is a C# [.Net] project, and so the installation or update (at least for the foreseeable future) is just a simple replacement of all the application files. So all the previous updates are invalid with the next update; in other words there is never any need to apply patch 1.1 in order to run 1.2, or 1.2 to run 1.3, etc.
Does that change anything?
No, it doesn't change anything. You still need to save the changes to your project file.
CodingGorillaLet me ask a follow up: what would the effect of not saving the updated project file be?
I just want to understand what is going on. When I do a build from the automated build, I'm only doing the most recent version using: wybuild.cmd.exe ThreeSixty.wyp /bwu /bu /upload -add="newVersion.xml" -vs="1.1.180.2" (where 1.1.180.2 is the version I just built).
Is that also a bad practice?
Let me ask a follow up: what would the effect of not saving the updated project file be?
Users running old versions of your software (versions that aren't in the wyBuild project) may or may not get all the files of your app. Obviously you want them to get the updates, so save the project file.
I just want to understand what is going on. When I do a build from the automated build, I'm only doing the most recent version using: wybuild.cmd.exe ThreeSixty.wyp /bwu /bu /upload -add="newVersion.xml" -vs="1.1.180.2" (where 1.1.180.2 is the version I just built).
Is that also a bad practice?
In this case you're building full-file updates (instead of patches). That is, you'll be delivering the full files to your users.
So if you don't mind deliver large updates to your users, then stick with this method. We recommend keeping track of all your previous versions so you can deliver tiny patches to your customers.
CodingGorillaSorry, one more question. Do I also need to keep the previously built files? IE. Let's just assume I'm building and deploying from my desktop. I Build version 1.0 from C:\My Project\bin\Release. I then add version 1.1 from the same location (as this is where my IDE is compiling the project to). Would I also need to keep version 1.0 around somewhere, because otherwise it's overwritten by 1.1?
Sorry, one more question. Do I also need to keep the previously built files?
Yes, and you'll need to store them in a separate folder. That is, don't overwrite old versions. (See step 6 in the step-by-step walkthrough).
My pleasure. If you have any other questions I'll be happy to help.
Tom HallWe are doing something very similar in terms of automated builds via TeamCity. We have been doing this via ClickOnce up to now, but for various reasons we are unhappy with ClickOnce and wyBuild seemed like an excellent alternative - and it is probably perfect for many scenarios but unfortunately not for us if it does not support incremental patches.Your product in general seems absolutely excellent but I think it would be hugely more useful if it catered for incremental patches, e.g. allowing us to only keep update patches for v1 > v2, v2 > v3, all referencing the same output folder. I think if we were to structure things the way wyBuild is intended for use as outlined above, unfortunately it would rapidly lead to a massive project file (we have a very large number of output files in our WPF application and I can see it growing with each update), a very large repository of app version folders, and an exponentially growing number of patch files for every possible update path - v1 to v2, v1 to v3, v2 to v3 etc. It also seems risky to be reliant on keeping all of this history. One of the few things I do like about ClickOnce is how it can resolve what has changed between 2 snapshots regardless of the number of updates in between.But having spent some time reviewing it, otherwise I'm really impressed with it, especially with the WPF integration.I hope you'll introduce incremental patches in the future!
Your product in general seems absolutely excellent but I think it would be hugely more useful if it catered for incremental patches, e.g. allowing us to only keep update patches for v1 > v2, v2 > v3, all referencing the same output folder.
Incremental patches are coming in wyBuild 2.7.0 (which will be released after 2.6.15).
Soon. It's being worked on concurrent with wyBuild 2.6.18.
