On Tue, 4 Dec 2001 08:54, Leo Sutic wrote: > > -----Original Message----- > > From: Peter Donald [mailto:[EMAIL PROTECTED] > > > > > While we are > > > still developing the next version the code will by necessity be > > > unstable and untested. Maybe you mean that with a release this close, > > > no new code should have been checked in? > > > > I think it should be checked into the proposal directories and then WHEN > > it is stable and it has achieved enough votes it can be moved to the main > > tree. Everytime someone starts messing with fundamental things and > > buggers it up my nightly builds go haywire. > > But then, whenever someone messes up a bugfix in the main tree your nightly > builds will go loco. If you include the CVS snapshots of all your dependent > libraries in your build, your build will not go through unless all CVS > snapshots are stable etc.
You mean I start relying on libraries that are declared to be stable ... say like Framework ... that they should be stable ? > Given a finite probability that the CVS snapshots > will not compile this does not scale to many dependencies. errr ... only if the libraries are not stable. I have had C projects that rely on a bunch of dependencies (20 not uncommon), while some maybe formalized libraries (like OpenGL + std C) many are just toolkits that were declared as stable. You know what ? If I had written some of these projects 8 years ago they would still compile today. There has only ever been two instabilities in "stable" libraries that I have encountered in C world - one was due to flakey drivers and one was due to a change in a library. > > Backwards compatability was thrown to the wind when experimentation > > occured on COnfiguration stuff - enough that I just turned off my > > nightlies. WOuldn't it be better that backwards compatability had been > > kept, experimentation done in a branch, another tree and then merged > > across? > > For reasons above, just because it has entered the main tree does not mean > that it will not be screwed up. but people should be making at least rudimentry efforts to warn people of changes and so forth. I try not to have dependencies on any non-stable products in my home projects. I still haven't moved everything to Phoenix from my old kernel/application server because of precisely this reason. Framework was declared to be stable so I think we should be treating it as such. > If you use the very latest bleeding edge > versions from CVS you will have broken builds. If I were you I'd fix my > Avalon dependencies to a released version - 4.0. Then, when you have a > 4.1rc1 or 4.1b that you consider stable enough you can move your projects > to it. Unfortunately that is not viable as we have no regression testing suite or any sort and I need to keep them compiling and testing on a daily basis to know what to expect. When Berin changed the format of DefaultConfiguration it screwed a few of my apps that rely on old serialized format, when he changed the SAX handler to require namespace be enabled and supported by parser he broke 4 of my projects. Trying to figure out these breakages after the fact, possibly months after the change would be way too painful. Thats why we have integration testing. I want to know as soon as possible when a break occurs. So I can either a) get change reverted b) fix my own project + add warnings to changes file -- Cheers, Pete *----------------------------------------------* | The best defense against logic is ignorance. | *----------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
