Nathaniel Smith wrote: > The requirement for landing a new automate command in mainline is that > the semantics (what it does) and interface (how you tell it what to do > and how it tells you what its done) must be fully documented and > tested. Also, we should be willing to keep those semantics and > interface fixed going forward. Having automate access to the
While this seems to work well enough for "simple" things I think it makes doing more complicated things overly scary. More complicated things are difficult to get right the first time so people either don't do them or we end up keeping broken things around rather than fixing them for the sake of stability. It would be nice if we could somehow say "this is here in automate land but is still experimental and may change." Could we simply add a stable/unstable status to the interface documentation or some sort of deprecation indicator that says "this old automate command is going to go away in version x.yy" or something? Yes, sadly, I'm still bearing the scars of automate inventory. ;) I would really like to see the new version of inventory merged at some point, however I'm also still not entirely convinced that's exactly what we want. Personally I think I liked the node id's in the format for example but I haven't been all that directly involved lately so who am I to say. Cheers, Derek _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel