On Sat, May 31, 2008 at 2:39 PM, Ali Saidi <[EMAIL PROTECTED]> wrote: > >> I'm not the expert on how this stuff works but I could see the benefit >> to a "stable" version of things and a "developmental" version. Or >> maybe, whatever release is the most recent is considered "stable".... > > It's a nice theory and maybe we'll have a stable repository in which we pull > changes from the development repo every so often, but generally the code > today is better than the code yesterday because we keep finding and fixing > little bugs.
Just another thought on this... although in an ideal world everyone would test their code thoroughly before pushing it, we know that doesn't always happen. I think we do need to distinguish at least two levels of stability; the version that most external people use that's been tested heavily (because most external people are using it), and the "bleeding edge" of the repo where we're committing. Is there an open source project that doesn't have "stable" and "development" versions? We might as well set up this structure from day 1, IMO. A couple thoughts on the details: 1. Seems like there's no need for a separate repo; we could just have a tag that's "latest stable" or something like that, and advance that tag as needed (maybe leaving the rev tagged with some more specific identifier like "stable of 2008-06-07"). Like what Nate did with symlinks in the system dir on zizzer, basically. This would be especially nice if the hg web interface that automagically generates tarballs can take a tag in the URL (I'm assuming it does); that way we can have a link for people w/o mercurial to just grab the latest stable copy. I'd say that link should be the default download link. 2. When people point out bugs in the stable release that are fixed in the tree and they don't want to upgrade to the bleeding edge, it will still be easier to help them b/c instead of saying "search the mailing list archive" we can say "look at changeset XXXXXXX", and they can pull out just that changeset and apply it as a patch if they want. (And I can already foresee a FAQ entry on just how to do that.) If they're smart they'll use mq to do that so they can kill the patch once they upgrade to a later rev via the repo. Or if they're not using hg at all, then that's their problem. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
