From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 162B61F9FD; Mon, 8 Mar 2021 02:55:00 +0000 (UTC) Date: Mon, 8 Mar 2021 02:54:59 +0000 From: Eric Wong To: Kyle Meyer Cc: meta@public-inbox.org Subject: Re: release timelines (-extindex, JMAP, lei) Message-ID: <20210308025459.GA23112@dcvr> References: <20210305222019.GB1010@dcvr> <87k0qk9lsj.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87k0qk9lsj.fsf@kyleam.com> List-Id: Kyle Meyer wrote: > Eric Wong writes: > > > But I'm deeply worried about unleashing a new on-disk format > > that's insufficient and being stuck supporting it forever > > (as I am with v1 inboxes)... > [...] > > * lei has a bunch of rough edges and I'm not comfortable declaring > > it as supported, especially when there's a risk of data loss to > > users. > > What are your thoughts on marking all things lei with a big > experimental / subject-to-change / may-eat-your-data warning? Yes, definitely experimental and may-eat-your-data. I hope the subject-to-change bit can be minimized, though I'll drop the '<>' in "lei q" JSON before release. I'm also considering diverging from mairix in making --augment the default behavior in "lei q". That would make things significantly safer, and --no-augment would be required to clobber existing outputs.