I must say that this is looking rather promising. I like and will support the idea. I think that this is especially important if the goal of dabo is to become easy to use. If this works out, maybe we should consider porting it to the ide framework as well. The reason I like this is that the majority of the users developing dabo apps don't develop the framework and just expect it to work. At the same time though, they want the newest features, bugfixes, etc...This is a very nice way of giving them a "stable" build that is more frequent than the point releases that works.
Now that it is explained further and I have had a chance to glance at the code, I support the feature. +1 from me. It supports the Vision of Dabo in respect to a framework (+ tools) that is easy to develop in and this should make things a lot easier for incoming users. Just my $.02. Keep up the fine work. Cheers, Nate L. On 7/10/07, Ed Leafe <[EMAIL PROTECTED]> 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 > > > > [excessive quoting removed by server] _______________________________________________ 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]
