Automatic update

joejoe2010

Hello,

has anybody of you already been investigating / implementing anything about realizing automatic updates?

My idea is that each time a openpetra-client is launched it checks if an update is available and if it's the case then also starts the installer (or updates the files without using the installer) . Of course the user should be asked before if he wants to install the update.

So one possibility would be checking on sourceforge.net/projects/openpetraorg/files/ in the html-code the version number of the current version
"Looking for the latest version? Download Alpha 0.2.10-1 (4.2 MB) "

A nice feature would be to know how many automatic updates actually have been realized. But on sourceforge we can't distinguish if a download is realized by a human (which then would be a new installation ) or by an already installed client (which then would be an update).

This could be solved by having a file on the homepage which contains the current version and a link to the download file. Via a wordpress-plugin it could be counted how often the file is accessed. (but on the other hand this neither wouldn't indicate directly how often the new version has been downloaded as an update because this file would be accessed each time a client is launched).

A third possibility would be having a second file on wordpress (with a useless content) which would be downloaded each time when a client gets an update-file from sourceforge. The access to this second file then could be counted by a wordpress-plugin.

Obviously the above suggested solution would only work for Windows because by the moment we only have a windows installer.
Furthermore it would only work for a standalone installation. Or may be the solution could be implemented for both - client and server.

As far as I know Timo is working on installing the client only in the userspace and not any more in the programspace (C:\Program Files). Would we then still need administration priviliges to be able to make an installation/update?

What do you think?

Greetings

Joachim

pokorra

We have a patchtool, that is basically working, but at the moment only for the remote installers.
This should download a zip file with only the differences to the currently installed version.
This way you could do counting of downloads on Sourceforge the normal way.

For the standalone version, we would have to work on making database upgrades. This is quite complicated for sqlite, since you cannot rename columns or tables in the sqlite database. So we would need to do a dump to yml.gz file, and reload again.

I personally would prefer to keep the Standalone version as simple as possible, mainly to be used for testing purposes, and soon offer a free basic hosting option for OpenPetra with automatic updates of the remote client and proper backup of the data. For a more sophisticated setup, more users etc, people would have to pay a monthly fee.

joejoe2010

Hello Timo,

thank you for your post.

In the meantime I aswell remembered the patchtool-thing and have investigated a little bit about it on the wiki and the bazaar repository.

You wrote that "This(the patchtool) should download a zip file". So what does the patchtool do for the moment? Does it - at the moment - get the zip-file from the server?
When is PatchCreation.cs executed?

So is it right that for the moment you would prefer not doing any changes about this update-thing?

Greetings

Joachim

pokorra

In the PetraClient, in
bzr.openpetra.org:8088/loggerhea ... entMain.cs you find the method void CheckForPatches().

The url for the zip file is part of the PetraClientRemote.config file:
bzr.openpetra.org:8088/loggerhea ... ote.config
<add key="OpenPetra.Path.RemotePatches" value="REMOTEPATCHESPATH"/>

PatchCreation: this is executed when you ran nant createPatch. I guess this currently does not work, we have lost that function when Thias redesigned the nant files.
I will add that when I need it again.
see the old version that still contains nant createPatch:
bzr.openpetra.org:8088/loggerhea ... ller.tasks

<target name="createPatch" depends="init">
<ExecDotNet program="${PetraToolsExe.dir}/PatchToolConsole.exe" commandline="-action:create -OpenPetra.PathTemp:${Tmp.dir}/patch -deliverypath:${Delivery.dir} -appname:openpetraorg-client-backup -oldversion:${OldVersion} -newversion:${NewVersion}" failonerror="true">
<environment>
<variable name="PATH" path="${environment::get-variable('PATH')};${OpenPetraRoot.dir}/csharp/ThirdParty/bsdiff"/>
</environment>
</ExecDotNet>
</target>

I am not the person to decide how updates should be made. If you want to improve it, you are welcome to work on that.

joejoe2010

Hi everybody,

almost a year passed since we've discussed this topic.

What is the current "stage of the art"? Would automatic updates be useful for remote clients only or as well for standalone?
Could anybody of the core team write a bit about this topic please?

Greetings
Joachim

pokorra

Just to say, that I am using automatic updates for remote and network clients, and it works fine now.

Standalone updates will become an issue, when all offices of OM are migrated to OpenPetra, because some offices just run Petra 2.x from one Laptop.

At the moment, the Standalone version is just for demonstration purposes, and is not supported at all for production use.

But perhaps Matthias should comment on the goals and what OM wants.

matthiasschwarz

I agree with Timo that an upgrade is not that easy to deal with and should not run automatically.
As far as automatic updates are concerned they will be triggered centrally (within OM) and most likely be done by IT-staff and not
by the users themselves. So a daily check for updates does not apply.
The whole issue of classifying updates, applying updates, forcing updates/upgrades, fallback scenarios etc.
needs some thorough investigation at a later stage, but we are not up to it yet.