First: It's been over a year since we've had a release of Scoop. I think it's about time we do so again, folks. When's a good time for everyone to have a developer meeting to figure out how we should do this exactly and what we need to do? 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 -STABLE branch will continue on based on the Scoop 1.0 codebase, and this is where point releases on the 1.0 branch will come from. It will have the expectation, though, that it should be working at all times. The -CURRENT branch, while it will initially be based on the Scoop 1.0 codebase, will quickly diverge from it and go off in its own direction. This is where the heavy development will occur, and this codebase is what will someday become Scoop 2.0. The thing about the -CURRENT branch is that it may or may not ever actually be working at any given moment, and you'd be insane to run a production site on it. As new, neat features get developed in the -CURRENT branch, though, they'll be backported into the -STABLE branch. -CURRENT would also be a good place to refactor old weird code (*cough*Comments.pm*cough*) without worrying about screwing up the main trunk. Anyway, that's my idea, and I already said I'd oversee the -CURRENT branch. Does anyone else have anything to add? -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/20031112/3d03e892/attachment.bin