On 7/10/07, Paul McNett <[EMAIL PROTECTED]> wrote: > 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? :)
Your ideal would be ideal. I see this as a solution to our problems pre-1.0 and a nice system for post-1.0 stuff. Until 1.0, this is a wonderful choice to eliminate the lag in the point releases. We can do it on trunk for now. Then, when our backporting bugfixes and releasing point releases improves we can go and switch the update system to move to stable. In short, I see this as a wonderful system for dabo application developers to get point releases in the future and a solution to the stable lag we are currently facing in the short term. > > These comments are meant to be constructive, not overtly critical. > > -- > pkm ~ http://paulmcnett.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]
