On 13/11/03 22:24 -0800, Andrew Hurst wrote: > > The only problem I see with it is the CURRENT codebase quickly dropping > the old code that has made developing for Scoop that much harder, and > replacing it with spiffy clean new stuff. Then new features getting added > that rely on the new whizbang code. I think "quickly" might not have necessarily been the right word. Or maybe it will. That would be kinda nice. > > You can end up with a couple things here: once that code is tested you > backport it to STABLE, with the cleanups as well; or the new features > don't get to be used generally until Scoop 2.0 because getting them into > 1.x would be too much work. > > Optimally the former would happen, of course. But from what I remember of > the codebase, with boxes relying on internal functions, it could get ugly > quick, and the latter could prevail. Also I think if that happens once, > it would probably snowball and happen from then on. Then you'd end up > like Slash and have to write a 20K line conversion script to go from 1.0 > installs to 2.0... The former would be ideal, of course. As far as boxes that rely on internal functions, my idea would be to either keep the same function names and arg lists for the rewritten code, or maybe add a Scoop 1.0 compatibility layer for old boxes. That way, we might hope to keep old boxes around and make the transition a little less painful. How's that sound? > > Of course, I haven't contributed code in over a year, so this is just an > unweighted opinion :-) > > -Andrew > Goddamn slacker. ;-) -j ---------------------------------------------- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ http://www.kuro5hin.org/ jeremy at satanosphere.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.kuro5hin.org/pipermail/scoop-dev/attachments/20031114/be2f76f9/attachment.bin