I apologize for not explaining myself more completely yesterday.
After working on this over the past few weeks, I finally got it all
working smoothly, and wanted to show it off. I probably should have
waited until today, and taken the time to explain things more clearly.
First off, let's start calling it "web updating" or "easy updating"
instead of "auto-updating". For some reason, a few people read "auto"
and assumed that I had somehow morphed into Bill Gates and want to
take over control of your computers. I only used the term because to
my ear it sounded like it would signify "easy" updating. Apparently
others didn't read it that way.
Let me state one thing at the start: there is absolutely *nothing*
in this feature that will *ever* change a single thing on your
computer without you explicitly telling it to do so. Period. So
please let's not hear more about Big Brother doomsday scenarios, OK?
A simple review of the code would have shown that clearly.
Here's how it works. First, if you do nothing, nothing happens. It's
completely disabled by default. You have to turn it on first before
anything happens. This is just like many apps, such as Firefox,
iTunes, TortoiseSVN, BBEdit, and many others work; even Ubuntu and OS
X has this behavior. You can also control the frequency it will check
with the server for available updates. There is no GUI interface for
this right now, but constructing one won't be very difficult. When
the framework is first run, we could ask the user if they want to
check for updates or not, and save their preference; there will also
be a way to manually check for updates.
OK, let's say that you turn on this update checking feature, and it
has been longer than your specified checking interval. Upon your next
launch of a Dabo app, it will call a web service to get the current
'released' build number. You can call that service directly with
http://dabodev.com/frameworkVersions/latest and see that you get back
the current 'released' Subversion build number.
BTW, I say 'released' in quotes because I'm not sure if this term is
confusing or clarifying. What I envision is a frequent pattern of
these build releases, with occasional point releases like we have
been doing all along.
If the value of this build number is greater than the value of
dabo.version["revision"], that means that your copy of the framework
is out-of-date, and so you are presented with a dialog informing you
that an upgrade is available, and asking if you want to upgrade now.
If you answer 'No', nothing happens, and your app continues as it
normally would. You will not be asked to upgrade again until after
the interval you specified has passed.
If you answer 'Yes', though, the framework asks the server for a
list of all changes since your current build, and will then update
your copy of the framework to the latest build. Your app then exits,
so that when you re-launch you are now running the current version of
the framework.
As I mentioned in my other post on distribution, this will be
completely unnecessary for those running Subversion. The use case is
for those who are using Dabo to develop apps, or who are just
exploring and want to see if Dabo is for them. Here's a typical
scenario:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1) We release version 0.x.x and post it as the current release
2) Several weeks later, someone reads about Dabo and is interested.
They grab the 0.x.x version, which is by now out-of-date.
3) They run setup.py, and begin by launching DaboDemo, AppWizard, the
Class Designer, or any other Dabo app.
4) They are presented with a dialog, asking if they want to enable
checking for updates, and if so, how often. They answer yes, and set
it to once a week. (This part is not done yet)
5) The app then checks the web service, and informs the user that
there is an update available.
6) The user OKs the update. After updating, they re-launch.
7) The user is now running the latest released build of Dabo, even
though the point release they downloaded was several weeks old.
8) A few days later, someone uncovers a bug in Dabo. I commit a
proposed fix to Subversion.
9) The fix I posted causes other unexpected problems, and a series of
Subversion commits ensue as I try to get things working right.
10) During this time the new user's system checks for an update.
Since we haven't marked a build as released yet, the web service
reports the same version it did the last time, and no update is
carried out. The user doesn't even see this happening.
11) A day or two later, I finally get everything working. The bug is
fixed, the side effects are gone, and everything is working OK.
12) At that point, I mark the current Subversion build as the latest
'released' build. Only Paul and I are able to do this.
13) The next time the new user's system checks for updates, it will
find the new build, and ask the user if they want to update.
14) The user answers 'yes', and gets the bugfix update, avoiding all
of the bleeding-edge problems I caused by my faulty bugfix code.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I hope that this post explains my vision more clearly, and can be
the basis for ideas on how to make this work as good as possible.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
