After thinking through many scenarios, I have come up with the next evolution in Seven Update. My original goal of Seven Update was to save bandwidth downloading updates and time creating and installing updates. I also wanted to make a uniform update platform for windows that provides an easy way for developers and users to update software. I realized Seven Update is not meeting those goals. Using SHA-2 hash checking to determine which files actually need updated is a great idea, however it complicates creating updates and it actually increases the bandwidth needed in many cases.

Recently I pushed an update for Media Center Classic Home Cinema. The program folder size is about 36mb uncompressed. Using simple zip compression, the folder size is about 5.5mb, that’s a big difference.

While I have not finalized the exact steps I do have a general outline. I plan on using xdelta 3.0z (or latest) to do patching, xdelta is the only windows solution that is open source and that supports 64 bit and files over 2gb. BSDiff can only handle a filesize of about 120mb. xdelta is actively developed and can be found here. I will use gzip archives to store each program revision in the SDK. It’s going to be important to keep old versions, I recommended 3 versions back. Don’t worry though, The SDK will generate a new full 7u package with each update you create. So if a user is using an old version that hasn’t updated in a while and a patch for it is not maintained, it will just download the full package. I am also toying with the idea of creating incremental and differential 7u packages, like 1.0-1.4.7u, so it doesn’t need to download 4 patch files and apply each one, that could be an option for the publisher to decide because it would save updating time and 0verall bandwidth but would increase initial upload bandwidth and storage space needed.

Example: SevenUpdate_Full.7u, SevenUpdate_1.0-1.1.7u, SevenUpdate_1.1-1.2.7u

The publisher will add only the updated files to the new update that person is creating. The SDK will have the ability to detect changed files to help to the work for you. The SDK will copy those files and create a 7z archive. The SDK will then generate patch files for each file. Creating registry and shortcut actions should remain the same. When an update is published, the SDK will  gather the patch file gzip them into a file called 7u. The default file name will be the version# of the update.

The SUI format will include various enhancements, file version #’s, last modified date of each file, an unique update id, and an update dependence option. The dependence option will allow the publisher to specify required updates to be installed along with the new update, that is where the unique update id will be used. UpdateFile.Source property will be removed, as it will be no longer needed.

So with this new process update distribution should be easier, only 2 files will be needed to be uploaded to a web server, the sui and the 7u file. The SUI as usual will contain all update information for your program and help Seven Update determine which updates are needed. Most of these changes will affect SevenUpdate.Sdk and SevenUpdate.Base projects. This will also lead to a UI update for the SDK, Seven Update shouldn’t be affected.

This will be a major update since it is going to affect almost all aspects of it’s base functionality, right now I am still in the preplanning stages. 1.x will still be maintained and updated as needed until 2.0 reaches a final release. Once the new version is in a working state , I will start pushing updates to the dev channel and introduce the SDK dev channel. The new installer should be done by that point.

So if you want to help with development, please don’t hesitate I could use the help, so this get’s done at a faster pace.