On 7/11/07, Simen Haugen <[EMAIL PROTECTED]> wrote: > 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.
I don't think this will be a huge problem. The vast majority of programmers that I have interacted with firmly believe in freezing all libraries used for an app at their current versions during deploy and recognize the risk of updating. If a user is developing a dabo App but not distributing it (i.e. coding for fun), the impact of having the update on or off is negligible. I would say that to mitigate your concern we should probably include a note in the deployment of dabo apps section in the docs. I guess the running when a dabo application is run is throwing everyone for a loop. The application doesn't care about the auto update. The reason that the update is checked when the application is run is that there is no other simple way beyond the user running a specific tool for the app to automatically check for updates. It was the simplest method by far, though I am going to make a suggestion to reduce confusion. I know some people (myself included) swear by hand coding dabo apps, but from what I have noticed the vast majority of people using dabo use the IDE tools. Correct me if I am wrong but doesn't VFP check for updates in the underlying framework through the IDE. That said, I like the approach of checking for framework updates through the IDE. I know it is not "automatic" the people not using the IDE tools, but it will drastically cut down on the confusion with regards end user using the update feature with deployed apps. It will also ensure that the developers don't accidentally leave the auto update on when the package the libraries for deployment. Maybe we can also have a tool so that users not using the IDE can run the tool in a cron job (or they can just fire up the IDE occasionally). The idea came to me last night so I thought that I would share it. Cheers, Nate L. > > > -----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]
