Hi Trevor,
I ran into the same questioning :-)
The way I chose is the following:
The app/exe itself is, of course, a launcher.
This launcher retrieves information from an external splash stack
and, among others, allows to set the label of the exe with the right
version number.
A very simple text file on our server allows to compare automatically
the user current version with the last one and alert him if needed.
When an update is available, needed files are downloaded and the
external splash screen is always replaced.
In case of 'big' update, a process allows with an invisible installer
to update all files, exe included and restart the software.
In addition, a check at every launch, verifies if all needed files
are there and downloads missing ones from the internet if needed.
So, in a few words, we have to ways of updating: a light one when
replacing a stack file or another one that replaces the whole app.
PS. For security, all files on disk are ciphered and restored in RAM
on-the-fly.
Le 4 févr. 08 à 18:23, Trevor DeVore a écrit :
On Feb 4, 2008, at 11:38 AM, Eric Chatonet wrote:
In complex projects that are known as needing future upgrades, I
prefer to have libraries, externals, pieces of the GUI, etc. in
specific folders.
Then, any component can be easily updated from the web when needed.
My two cents ;-)
Eric, your mention of updating an app over the web and organizing
individual pieces into their own separate folders brings to mind
some issues I've been thinking about recently in regards to auto
updating. So in the interest of sharing some additional thoughts on
the subject of auto updating, here they are.
When I originally implemented auto updating in one of my
applications I would create updates that only updated specific
stacks in the installation. I thought it was really cool that
Revolution could update any stack on the fly and then just reload
without restarting the application. That application has been
around for a number of years now and has received numerous updates.
What I found was that this approach ended up being more complex
then I would have liked as I had to determine which stacks had been
changed since the last version and then only include them in the
update I pushed out.
I decided I wanted an auto update architecture that required as
little thinking as possible come publish time. Add some release
notes, click a button and upload the files. I didn't want to have
to keep a log each time a script changed anywhere in a stack so
that I would remember to update it when I pushed out the next
version. I also wanted to have an exact snapshot of every file in
the installation for each release so that I could be look at the
exact same code that was running on the end-user machine if they
report a problem with version 1.2.3.
So when I revised my auto update architecture I designed it so I
could push out:
a) new program files (stacks, externals, supporting docs, etc.) or
b) just the executable files (to push out engine bug fixes) or
c) both a and b.
This was much simpler to deal with on my end and it made me feel
good inside that I wasn't making the user download the ~2MB engine
each time if they didn't need to. Since I was no longer updating
the application at the stack level I wasn't as concerned with
splitting up stacks into different files on disk.
I've now been using this update architecture for a little over a
year now. Over that year I've seen a number of users write in
thinking that they weren't running the latest update because the
File Info dialog for the executable said 1.x instead of 1.x.x (The
about box does report the proper version though).
So now I'm of the mind to always update the entire application
whenever I push out a new public release for a consumer
application. I can still provide the benefit of the app updating
itself and relaunching with no intervention and there is less room
for confusion as to what version they are running since the File
Info dialog for the executable reports the proper version. I figure
a couple of extra seconds (or minutes depending on connection
speed) to download everything is worth it in the end.
Regards,
--
Trevor DeVore
Blue Mango Learning Systems
www.bluemangolearning.com - www.screensteps.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Best regards from Paris,
Eric Chatonet.
----------------------------------------------------------------
Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: [EMAIL PROTECTED]/
----------------------------------------------------------------
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
