> Second: I bounced this idea of rusty yesterday, and he seemed to like > the idea. Basically, I think after this next release of Scoop (which I > think we might as well make 1.0), we should branch Scoop into -STABLE > and -CURRENT branches, much how FreeBSD does its development. > ... 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. 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... Of course, I haven't contributed code in over a year, so this is just an unweighted opinion :-) -Andrew