From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
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 <e@80x24.org>
To: Kyle Meyer <kyle@kyleam.com>
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: <meta.public-inbox.org>

Kyle Meyer <kyle@kyleam.com> 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.