On Tuesday 10 July 2007 13:17, Ed Leafe wrote: > 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 This sounds great. +1 from me. However, will the releases be easier to maintain? It sounds like it - but I see SVN changing so fast that it might be difficult to flag as an update release. I hate the words "stable" and "unstable" in the context of Dabo. So I really like the use of "update".
-- John Fabiani _______________________________________________ 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]
