Auto-update of native application bundles

[Daniel Zwolenski]

I think I understand but please clarify any of the below if I got it wrong.

Would it be correct to say that the main difference is that in your
proposal you are working out the 'delta' update at compile/packaging time,
whereas in my solution the app works out the 'delta' at runtime when an
upgrade is requested. Assuming this is right, then:

Because you are working deltas out at compile time you can bundle the
updates into a single image file and avoid having an app-profile. In my
solution I need everything extracted on the server with an app-profile so
the app can work out the diff in jar versions at runtime. Your solution is
definitely nicer on this front.

On the other hand, because I work deltas out on the fly I don't need
'delta' image files and any old version can always update to the latest
without downloading the full bundle even though no 'delta' file exist. In
your solution we have multiple deltas to maintain and the more versions you
have the more deltas you have to maintain (or not use deltas, resulting in
larger downloads). If a delta is not available for a specific older
version, then the app will have to download the full update and install
this.

Advantages and disadvantages both ways, it would be good to get input from
the community and other JFX'ers on this.

Just as a point of reference and for extra clarity, I'll step through the
process for a theoretical app.


*Using your proposed approach (as I understand it, please clear up anything
I got wrong):*

Say we have an app called "MyApp" and we've just finished writing version
1, which contains myapp-1.0.jar and log4j-1.2.jar.

Using your tools we then build "myapp.msi", "myapp.dmg" and "myapp.rpm" and
upload these to our site.

So for the release of version 1 we upload the following files:

   - myapp.msi (50MB)
   - myapp.rpm (50MB)
   - myapp.dmg (50MB)

A month later we are ready to release version 2. The only jar that has
changed is myapp.jar but we've also added the spring-3.0.jar as a
dependency, adding 5MB compressed. We use your tools to build the new msi,
dmg and rpm and we upload these over the top of the old ones so anyone who
downloads our app will get the new version.

We also create a 'full' update file and upload this to our server. Since
this must contain the JRE, I assume it is one per platform?

Additionally we want to create a 'delta' update for this release, so we
point your delta building tools at ??? (did we have to create and store an
old image file from version 1?) and it works out the binary diff and
produces a 'delta' file (can this be one for all platforms or does it need
to be one each?).

So for the release of version 2 we upload the following files:

   - myapp.msi (55MB)
   - myapp.rpm (55MB)
   - myapp.dmg (55MB)
   - full-image-win.zip (55MB)
   - full-image-linux.zip (55MB)
   - full-image-osx.zip (55MB)
   - myapp-delta-v1-to-v2.zip (8MB)

A few months later we are ready to release version 3. This time we only
change the myapp.jar, nothing else. We use your tools again to build the
new msi, dmg and rpm and we upload these over the top of the old ones so
anyone who downloads our app will get the new version. Again, we also
create 'full' update files (one per platform) and upload these to our
server.

Additionally we want to create a 'delta' update for this release. We need
to create two delta files - one for moving from version 1 to version 3 and
one for moving from version 2 to version 3. So we point your delta building
tools firstly at the version 1 image, and then secondly at the version 2
image (which we've had to keep in our source control for this purpose, or
we have to roll back to the old code to build these older images).

So for the release of version 3 we upload the following files:

   - myapp.msi (55MB)
   - myapp.rpm (55MB)
   - myapp.dmg (55MB)
   - full-image-win.zip (55MB)
   - full-image-linux.zip (55MB)
   - full-image-osx.zip (55MB)
   - myapp-delta-v1-to-v3.zip (8MB)
   - myapp-delta-v2-to-v3.zip (4MB)

If the delta is platform specific, either because it contains native files
or a new JRE then we would need one delta per platform, and we would end up
with x 3 zips of the deltas (or more if you have different versions for
32bit vs 64 bit, etc).

For version 4 and beyond, the permutations of deltas continue to increases
(i.e. v1-to-v4, v2-to-v4, v3-to-v4) assuming deltas are used.
Alternatively, the developer stops maintaining deltas but then upgrades
fall back to full downloads (i.e. 55MB instead of say 4MB) to move up
versions.


*Using my POC approach*
*
*
We have our same app "MyApp" and we've just finished writing version 1,
which contains myapp-1.0.jar and log4j-1.2.jar.

We then build "myapp.msi", "myapp.dmg" and "myapp.rpm" and upload these to
our site.

For the release of version 1 we upload the following files:

   - myapp.msi (50MB)
   - myapp.rpm (50MB)
   - myapp.dmg (50MB)

A month later we are ready to release version 2. The only jar that has
changed is myapp.jar but we've also added the spring-3.0.jar as a
dependency. As usual, we build the new msi, dmg and rpm and we upload these
over the top of the old ones so anyone who downloads our app will get the
new version. Additionally we now upload the new app-profile.xml (which can
be generated) and the extracted bundle of our app.

For the release of version 2 we upload the following files:

   - myapp.msi (55MB)
   - myapp.rpm (55MB)
   - myapp.dmg (55MB)
   - unextracted application bundle (15MB)
   - zip of the JRE for windows/linux/OSX (30MB each) //  in a better world
   JRE zip is downloaded directly from Oracle and would not need to be
   uploaded by me!

A few months later we are ready to release version 3. This time we only
change the myapp.jar, nothing else. We build the new msi, dmg and rpm and
we upload these over the top of the old ones so anyone who downloads our
app will get the new version.

Since the only JAR that has changed since the last release is myapp.jar,
this (and the new app-profile.xml) is the only thing we need to upload to
the server.

So for the release of version 3 we upload the following files:

   - myapp.msi (55MB)
   - myapp.rpm (55MB)
   - myapp.dmg (55MB)
   - app-profile.xml (tiny)
   - myapp-2.0.jar (4MB)

For version 4 and beyond the upload sizes are similar, the permutations do
not grow as more version are released, etc.


Just as an aside, in both my POC and your approach it would be possible to
create an "on line" installer that meant the MSI, RPM, DMG, etc's were all
tiny (a couple of MB) and they would then fetch the 'full' installation and
install it. This would make uploading a lot simpler as you wouldn't have to
upload the 150MB associated with the new msi, rpm, dmg everytime. I think
this is a version 2 feature but I also think it's good that the options we
are looking at leave the door open for this.