On Thu, Feb 02, 2006 at 11:03:30AM -0800, Graydon Hoare wrote: > There's "what needs to be done" and "what needs to be done which will > cause compatibility / migration events". There's still a fair bit to do, > but I believe there are likely only 2 or 3 more possible migration / > protocol-compatibility changes on the horizon.
Right... to me, 1.0 basically means: -- no giant rough edges or horrible bugs. Rough edges have been disappearing quite steadily, and thanks to the test suite and all our horrible bugs generally stay pretty limited, so this is unlikely to be much of an issue. -- we can be _really really certain_ that our basic data structures and stuff are stable, and we will be able to make strong compatibility guarantees going forward. This is the hard part, since this requires a really high degree of confidence that we haven't missed anything, and furthermore we want to avoid the situation where we commit to a format and then advances in theory make it obsolete. (Imagine if we had declared 1.0 back before we invented revisions! Or consider darcs, which _after_ declaring 1.0 discovered that their fundamental algorithms and data structures were flawed and needed to be re-derived from the ground up. Or the various systems that are heading towards 1.0 without getting renames nailed down...) Our intention is that the new roster-friendly revision and manifest formats will suffice for the indefinite future, but I wouldn't be confident committing to 1.0 on _any_ such format without, say, at least 6 months of real use burn-in by a diverse group of projects. But, the actual main coding there is done, so we're moving on to the next big pieces to stabilize...: > - Change to the cert format accompanying work on "management > branches", or "ACLs", or whatever we wish to call it. This will > probably involve re-issuing all the certs in your database, but > probably not involve rebuilding your revision graph. Right. > - Modifications to netsync to support partial-pull operations, which > might involve a database migrate command to change the schema and > will almost surely involve a netsync protocol-number bump. I would phrase this instead as "think hard about how to make it possible to extend netsync in a backwards-compatible way". Partial pull is probably not the only change we'll want to make; we should have some way to do basic feature negotiation or whatever to figure out whether the other side can do partial pull, or whatever else we add. Actually supporting partial pull or not seems less critical, 1.0-wise :-). > - "Future-proofing" of the cert / revision format by including > a cryptographic algorithm parameter. Possibly necessary, > possibly not. It's entirely possible that discussion will > conclude that epochs are sufficient for this problem; we > just haven't had the discussion yet. I'm a bit on the fence here; algorithm agility is mostly useful for things like SSL, where you call, talk, then hang up. In monotone, we never get to hang up, the old data always still needs verifying, no matter how good this year's attacks are. So just making full migration as smooth as possible seems like it might be the only real option... It would be nice to migrate to an algorithm whose future prospects look better than SHA1 before hitting 1.0. But who knows when consensus will be reached on that... So, yeah, basically -- 1.0 is the goal, and we're closer now than we've ever been, but data and design integrity take time to establish. So we're working on it. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel