From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: How to do a beta release on ELPA? Date: Mon, 26 Oct 2020 16:49:24 -0400 Message-ID: References: <87wnzfvreo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28674"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 26 21:50:43 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kX9Rz-0007Ms-T1 for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Oct 2020 21:50:43 +0100 Original-Received: from localhost ([::1]:34980 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kX9Ry-0004bd-Q1 for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Oct 2020 16:50:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kX9Qq-0003kV-4l for emacs-devel@gnu.org; Mon, 26 Oct 2020 16:49:32 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10146) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kX9Qn-0003fk-3u for emacs-devel@gnu.org; Mon, 26 Oct 2020 16:49:31 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9FE8F441224; Mon, 26 Oct 2020 16:49:27 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F416C440466; Mon, 26 Oct 2020 16:49:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1603745365; bh=E/qXP+VYriGg2uOQH0x2k/oe/rNxyuHvRbDaVsiHnis=; h=From:To:Subject:References:Date:In-Reply-To:From; b=nT9K7MeIFVTnhFQsu5hN37rn2o/jDr7DiaijxJ7SiHTIVg8echuRg9IhnCGAs1ZbN pIVpCxWnzH8o4w9CuLcWHagwZ+lNNicMTsURWX4I3/V1ZI0kgH1bqL8IKAwcBfV9P/ eGn5vwsl69PiksB2SkVJoQF2UiI9rxSmD80XGufptbaXamKuBQL3NkacimTIKZ583V Exb1+Gi1HvtdfKQYCfDDai55R8HW6JvvEGkb4h6lgezbNDQXGAFZRdZX7TzDholHDh Ga7xrJRpyu5WWZyykTXNN+CzGXc8CHNO/lnMlJITBfS9uJD4uVhZVnxU7KzHW/x1xs Rg0TvXOc622Pg== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D6C5F120314; Mon, 26 Oct 2020 16:49:25 -0400 (EDT) In-Reply-To: <87wnzfvreo.fsf@gnu.org> (Tassilo Horn's message of "Sat, 24 Oct 2020 12:39:59 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/26 16:49:27 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258481 Archived-At: > We've worked hard lately to make GNU AUCTeX use lexical-binding. Cool! > I don't think there are too many people running straight from our master > branch, so I guess we should do a new ELPA release pretty soon to get > more testing. But is there a way to release a new ELPA version just for > the adventurous? Not really, no. [ I mean, other than the obvious ones that involve more work on your side and/or on the side of those who want to install the new version. ] I'd like to create an alternative ELPA archive built from elpa.git but using the latest code (kind of like the non-stable Melpa), but that's been a TODO item for a while already and I've not even tried to get started on it. If such a thing existed you could just update the auctex code without bumping the "Version:", and people following that "gnu-snapshot" archive could then update the bleeding edge code. > 1) Make a separate auctex-beta package which would just be the same as > the normal one except with a more recent release. Sounds like a lot of trouble (including dealing with users which have both packages installed, including an older `auctex-beta`, etc...) > 2) Just do a normal ELPA release and if things break for some users tell > them how to pin auctex to version 12.3.1 for the time needed to fix > their issues. That's what I'd recommend, yes. I'd definitely give it a release version that sounds like "major release". We're way past "2.0", so I'll let you find the next best choice. > With option 1), I eschew the amount of maintenance required. And what > should packages do that depend on auctex? Nothing. > Now they need to depend on auctex or auctex-beta. I wouldn't bother. > Oh, and we'd need to declare both of them as being incompatible to each other. There's no such mechanism. > With option 2), I guess it could harm users who don't know how to reach > out for help. Maybe emit a warning during compilation or upon "first use", with an appropriate description of the kind of problems that can happen. Many users still won't read it, but it increases the chances that they'll find someone who has. > Are there any other (preferably better!) options? Option 1: change the code so as not to introduce such backward incompatibilities (e.g. Calendar ended keeping nasty dynamically scoped vars like `date` and `month` in order to maximize compatibility with existing code). That can't be a 100% solution tho since there can always be people who used non-documented vars via dynamic scoping. Option 2: rely on the quick&easy release process: as soon as you hear of one incompatibility, you immediately adjust the code (typically to mark some var as dynscoped) and make a new minor release. Option 3: (getting really creative here) make sure you new code makes no other changes than switching to lexical-binding and then do temporary release: release 12.3.2 with lexical-binding, then a week later release 12.3.3 without lexical-binding (i.e. reverting to the previous code) and work on fixing the incompatibilities found along the way, then try again with the new&improved lexical-binding code, maybe leaving it for a month instead of a week, ... If you insist, I'm sure I can come up with an even more fun option 4. Stefan