Ed Leafe wrote: > On Jul 10, 2007, at 5:50 PM, Paul McNett wrote: > >> I'll say it again: regular users using the trunk is too close to the >> bleeding edge. They *should* be using the most recent stable version. > > I have to *strongly* disagree, and I think I know why we have such > different POVs: I'm writing the tools for our users, and you're not. > Let me explain. > > In the course of writing the Class Designer, I constantly find > limitations in the framework. Either something is not possible, or it > is possible only with a lot of mindless, repetitive code. When I run > into a situation like that, I add that missing piece to the > framework, and then write the code for the tool to use this new > feature. The tool benefits, of course, but so does everyone else, as > they now have access to this new capability.
We are still running into lots of limitations in the framework because it is still pre-1.0. You've been writing most of the tools for the users, and finding limitations, and I've been writing a large application for a client, and finding limitations. We've both been improving Dabo as we go. > As soon as I do that, though, nobody using the 'stable' version can > use these tools, since by definition nothing new can ever be added to > the stable version. They are going to have to wait for the next full > point release before they can use the tool. This is unacceptable, > since full point releases are so far apart. Our last was 2 months > ago; before that: 6 months; before that, 8 months. Telling someone > that they can't use a tool for several months just doesn't cut it. The problem is the lag in point releases, not the system we have in place already. Developers interested in testing the new stuff should be the ones using the bleeding edge trunk; user/developers that want to use the framework for their applications should be using the stable branch. Please note that the above statement is the "ideal". I realize that it hasn't been practical to recommend people actually use the current stable branch, because of the lack of backporting bugfixes to current point releases, as well as the lag in releasing new point releases. Indeed, I currently don't follow my own recommended approach: I pick a recent dabo trunk revision that seems to work well enough, and roll that into my .exe. However, post-1.0 I expect this situation to change (I'll only roll in the latest stable revision). > You bring up an excellent point: using the trunk is indeed too close > to the bleeding edge. That's why I don't want to have to tell people > interested in using the visual tools that in order to do so, they > have to stay on that bleeding edge. The update system I have devised > satisfies both concerns, since we only mark a build when we are > adequately convinced that it won't cause bleeding. This may take > several days of testing and feedback, but once it is apparent that > there is nothing nasty, we mark that as the current build and make it > available to all. I agree, and see the value in the web update system you've put in place. However, I do have concerns. 1) The time spent testing new trunk revisions to make sure they are fine enough to make into a web update could be spent rolling a new point release. 2) Potential for us to miss something important in a marked web update, perhaps that takes down the ability for web updates to work anymore. 3) Dilution of the whole point of the stable branch. We haven't had time to properly maintain the stable branch and make point releases in a timely manner; now on top of maintaining that we are going to maintain a live update system on trunk. The live update system seems to me to be a superb way to distribute official point releases and point-release minor updates, post-1.0, when we are much better at backporting bugfixes and releasing regular point releases. It doesn't seem to be a great way to distribute trunk releases, as (ideally) the trunk should be used by developers of dabo and that superset of power users that want to help us test the new stuff, in which case subversion would be the update tool of choice. Can you at least concede that my ideal would be ideal? :) These comments are meant to be constructive, not overtly critical. -- pkm ~ http://paulmcnett.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]
