I think it is a good idea to let dabo have an update feature so new developers can get updated versions by other means than svn. I myself tried to use the stable version, but quickly switched back to trunk as I needed bugfixes and new features. The stable releases of dabo just lags too much behind and perhaps also have unfixed bugs as Paul mentioned. I understand that many developers might be put off if they have to use the trunk and get crash-bugs or other annoyances. Having this update feature will be a 'stable' bleeding edge version, and I really like that idea.
On the other hand, I completely agree with Nate that this should not be available for end users. All my applications have been using different versions of dabo, and if whenever I switch dabo version and make changes to applications I often need to make changes to get them to work. Some of my applications have its own auto-update feature, and I think is up to the application developer to add auto-update for end users, not the framework. I think the update feature is a good thing, but as Uwe has stated, put it in a separate tool just for developers. We don't want end users updating the framework without us being able to test it first. When putting this in the framework new dabo users might think "Boy.. Auto updating without doing any work, that's great!" and turn on the updates in end user applications without knowing the consequences. They might be put of that dabo fucks up their applications when something breaks, because with this option in the end users hands things will break. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nate Lowrie Sent: 11. juli 2007 07:48 To: Dabo developers' list Subject: Re: [dabo-dev] Distributing and updating Dabo On 7/10/07, Dj Gilcrease <[EMAIL PROTECTED]> wrote: > I guess I'll toss my 2 cents in to the ring on this issue. > > I fully support auto/easy/web updating of dabo. Now I do think that > this should be handled by the applications using dabo, and not ask for > user input. The reason for this is end users of an application are > rarely going to know if they should be updating dabo or not, the > developer of said application will. I also think that it should not > auto Exit when it is done updating, maybe make an UpdateComplete event > that the Developers can catch and do something with (like running > though sys.modules and removing everything that dabo and their app > imported, then reimport it, thus getting the new version without > restarting the app) This is not how I want things to work. When I release applications for end use, they are specified to be used with certain versions of any underlying frameworks and libraries that are used by the app. The issue is that any version, both previous and future, can break the app. My apps need to be reliable, and I don't want to worry about this. I am under the impression that this is not an end user item. If I develop an end user app, the end users using it don't need framework updates for the app to work. They don't even need to know the framework exists. It's pointless to update the framework, and the upgrade is a reliability risk. This update feature is for developers of the dabo applications to easily get new releases. Remember that the VFP world is largely visual based and tools like this are necessary for the framework to draw a large developer base. Don't like the event idea. It's extra work for all applications. Developers should use it to upgrade. End User apps can and should turn the upgrade off, especially when deployed. > > Since I have not looked closely at the code I am not sure if when it > upgrade it just grabs 'release' or it grabs a specific build number. > If it grabbs a specific build number then you should allow developers > to specify a maximum build number for their app, and thus allow dabo > to upgrade/downgrade itself for each end user application that uses > it. (This coupled with the event idea should allow each application > developer to guarantee a working version of dabo for their app, > without having to rely on end users upgrading or NOT upgrading when an > upgrade happens to break you app) > > [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]
