Versioning per user

Hi Jordan,

In our scenario, we have different installs working with different versions:

company 1 uses version 1.1company 2 uses version 1 (update has not been rolled out yet to company 2)the version the company is using, is recorded in DB, and can be delivered via webservice for example.only after company 2 vesrion has been updated in DB to 1.1 , the update should be rolled out.

I'm afraid I don't completely follow you. Do you want to only release a new version of your software once company 2 updates to 1.1?

wyBuild builds patches between all versions, so there won't be any problem if they wish to skip 1.1 and just update directly from 1.0 to 1.2 (or beyond).

My Question is : Can WyUpdater be customized by us, to include such functionality? How can we add logic to the updater decision if the application is out of date?

Yes & yes. wyUpdate is completely open source. It's licensed under the BSD license so you can modify it however you wish.

Can an update be checked as "Optional - user may opt to update or not" or "Critical - user must update"?

Well technically all updates are optional. For instance, even if Microsoft marks a Windows update as critical the user can still skip the update.

So I'm not quite sure how to answer this question. As it stands there's no way to mark an update either optional or critical. If you use the AutomaticUpdater control you'll be able to detect in-code what the latest version is. And from there you could come up with a version scheme to differentiate between "critical" and "optional" update.

For instance, you could increment the "minor" part of the version number (e.g. 1.X) to signify a critical update and increment the "revision" part of the version number (e.g. 1.1.X) to signify an optional update. Then you could use the "Version" property of AutomaticUpdater control to decide whether to install an update or not.

Am I understanding you, or have I completely missed the mark?

Thanks for the quick response!

1.If we customize the source code - is there a way to do this so we can still get updates, features, future versions?I.E. , use some Plugin/Extension?

2.is there documentation for the source code? so we know where to make our changes without damaging some functionality unintentionaly?

Thanks,Jordan

1.If we customize the source code - is there a way to do this so we can still get updates, features, future versions?I.E. , use some Plugin/Extension?

Well, if you use the AutomaticUpdater control & the method I suggested then you won't need to modify the wyUpdate source at all. This is by far the easier method.

That being said, if you want to alter the source the best way to keep up-to-date with our changes is to check out the latest revisions of wyUpdate from our subversion repository:

svn checkout http://wyupdate.googlecode.com/svn/trunk/ wyupdate-read-only

If you do do this, I recommend only checking out & merging your changes on revisions we tag (see http://code.google.com/p/wyupdate/source/list . Notice the "tag 2.5.10" revisions). The revisions that come between "tags" aren't guaranteed to be stable.

Lastly, you'll need to create a new project in wyBuild to manage the versions of your modified wyUpdate. This way your modified wyUpdate will be able to self-update. Then simply alter your product's wyBuild project to reference you wyUpdate's *.wys file. Click File > Properties, and then enter the site where you're hosting the wyUpdate server file:

[attachment=0]Properties.png[/attachment]

2.is there documentation for the source code? so we know where to make our changes without damaging some functionality unintentionaly?

The documentation is in the comments. Unfortunately there's no document to explain every part of the code. I would just recommend running in Visual Studio & stepping through the code one line at a time. It's fairly straight forward.

We control the version in our database. When wyUpdate is called from managed code we pass in versioning information as arguments to determine which version it should be updated to. Our update server has different folder destinations for different versions so it will only increment to the specified version in the update rather than the latest. This also allows application administrators to "release" what version of the update that they want from the parent application.

You can accomplish this with the -server argument specifying the folder path.