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
