From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kyle@kyleam.com>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H4,
	RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham
	autolearn_force=no version=3.4.2
Received: from out2.migadu.com (out2.migadu.com [188.165.223.204])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by dcvr.yhbt.net (Postfix) with ESMTPS id C64791F9FD
	for <meta@public-inbox.org>; Sat,  6 Mar 2021 18:31:10 +0000 (UTC)
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1;
	t=1615055469;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=kouZ+mn05yGiFqvu9cUVnhXGdlHQdbKew9/Rj7UxVxg=;
	b=zM4EAJQXXMj5DWtM1OVBAOAl/kmu2xerv5BKIV94pcKnXzM9PsrchzvMEi+qINbqCTP3V0
	fdHw6rrqi7lBC4Om7MTAtnYIUwK5FRsPSyXvgZVp6xXeUC/7XhNwCLyTxPl2zxvYsexLND
	bgrreO2b74y7EHiGT/1oK1FGyekYoilk3+Oai4Vtc5yHOvtCfTDr86/yyFKpmbcegH5FYQ
	q19a5J1PjodOXwMkrBifiXpwoDD9lcnMsDzklNoYuRhZa+LMkG8gZohJnUTgp/tfhpzhBV
	i/EatEmH5U564+gxTUzcRm43hEhkeic07bQm0yqk1hmOlwFNaUM3HbCwlngCUA==
From: Kyle Meyer <kyle@kyleam.com>
To: Eric Wong <e@80x24.org>
Cc: meta@public-inbox.org
Subject: Re: release timelines (-extindex, JMAP, lei)
In-Reply-To: <20210305222019.GB1010@dcvr>
References: <20210305222019.GB1010@dcvr>
Date: Sat, 06 Mar 2021 13:31:08 -0500
Message-ID: <87k0qk9lsj.fsf@kyleam.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Migadu-Flow: FLOW_OUT
X-Migadu-Auth-User: kyle@kyleam.com
List-Id: <meta.public-inbox.org>

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?