From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: How to do a beta release on ELPA? Date: Fri, 30 Oct 2020 21:32:37 +0100 Message-ID: <87361vpi8q.fsf@gnu.org> 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="28464"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 30 21:33:52 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 1kYb5s-0007IZ-1m for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Oct 2020 21:33:52 +0100 Original-Received: from localhost ([::1]:51724 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYb5r-0008Cj-0n for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Oct 2020 16:33:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54728) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYb4k-0006nU-Bp for emacs-devel@gnu.org; Fri, 30 Oct 2020 16:32:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52218) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYb4k-0000US-1T; Fri, 30 Oct 2020 16:32:42 -0400 Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:33713) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1kYb4j-0004fs-El; Fri, 30 Oct 2020 16:32:41 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id E9E8E27C0054; Fri, 30 Oct 2020 16:32:40 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 30 Oct 2020 16:32:40 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleehgddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefvrghsshhi lhhoucfjohhrnhcuoehtshguhhesghhnuhdrohhrgheqnecuggftrfgrthhtvghrnheptd elieffkeeuffduueeffefhiedtjeeutdeuveegfffgtdejleekheegkeetkeevnecukfhp peelfedrvdefiedrudefgedrvdduudenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehthhhorhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgr lhhithihqdekieejfeekjeekgedqieefhedvleekqdhtshguhheppehgnhhurdhorhhgse hfrghsthhmrghilhdrfhhm X-ME-Proxy: Original-Received: from thinkpad-t440p (p5dec86d3.dip0.t-ipconnect.de [93.236.134.211]) by mail.messagingengine.com (Postfix) with ESMTPA id 25DB63280060; Fri, 30 Oct 2020 16:32:40 -0400 (EDT) Mail-Followup-To: Stefan Monnier , emacs-devel@gnu.org In-Reply-To: (Stefan Monnier's message of "Mon, 26 Oct 2020 16:49:24 -0400") 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:258563 Archived-At: Stefan Monnier writes: Hi Stefan, >> 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. Ok, I guessed so. > 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. You gotta have plans. >> 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. Yes, we'll release it as GNU AUCTeX 13.0.0 on ELPA and when things have stabilized, we'll do a 13.1 tarball release. So the current version 12 is the last one of the pre-lexical-binding era. >> 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. Yes, I guess such a first use message pointing to the docs where we describe exactly what has changed and how to migrate would be a good solution. >> 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. Nah, I'm happy those are all gone. :-) > 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. Yes, that's definitely what we are planning to do and the reason it'll be on ELPA first. > 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, ... That's creative indeed! > If you insist, I'm sure I can come up with an even more fun option 4. Please stop it! ;-) Thanks, Tassilo