From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "=?UTF-8?Q?Martin=20Edstr=C3=B6m?=" Newsgroups: gmane.emacs.devel Subject: Reconsider defaults for use-package-vc-prefer-newest Date: Sat, 14 Sep 2024 14:09:09 +0200 (CEST) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13677"; mail-complaints-to="usenet@ciao.gmane.io" To: "emacs-devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 14 14:10:33 2024 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 1spRbe-00038u-Q7 for ged-emacs-devel@m.gmane-mx.org; Sat, 14 Sep 2024 14:10:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spRav-0004fX-Kx; Sat, 14 Sep 2024 08:09:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spRah-0004fH-Ef for emacs-devel@gnu.org; Sat, 14 Sep 2024 08:09:28 -0400 Original-Received: from mailtransmit04.runbox.com ([2a0c:5a00:149::25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spRad-0000pt-ML for emacs-devel@gnu.org; Sat, 14 Sep 2024 08:09:26 -0400 Original-Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1spRaP-007x7d-Sl for emacs-devel@gnu.org; Sat, 14 Sep 2024 14:09:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.eu; s=selector1; h=Message-Id:Date:Subject:To:From:MIME-Version: Content-Transfer-Encoding:Content-Type; bh=0Jp7u2Yx4xOhIU7y3qUIScgHoEVwSFnRlohVofmAO1A=; b=aYbfbcrydnYBk2XNGbEjj2xSYr ivM3egG0qyiTPa+SR7UJiie4GOHpQRd+b1X7/rIxqnBkRF70Vfhf3DOaPWFK94CKFzDgEkVPYZSbV VykR8U5k4XMbxNc5POHYLHBaPvffJftVkFa2wI28AtrfYskcAFnrgUoWQ8Kajoj8sRHaOENZslfbo xJ+/tZMGYA0RC5UOtV8KnDe2m43a9refv66XNuEidBxzT84xgLVTBFWjfr5gnDWCOfjNNm4pqCpEy URo7n0ZfSeO7jk3k+XIE7r2CmoPitUjiEh7bQ7AirAu7aRNtXG6TuvfcdULD5S8WeMmWeqrhZAPvb Kpbc8wAg==; Original-Received: from [10.9.9.128] (helo=rmmprod06.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1spRaP-0000YK-7u for emacs-devel@gnu.org; Sat, 14 Sep 2024 14:09:09 +0200 Original-Received: from mail by rmmprod06.runbox with local (Exim 4.86_2) (envelope-from ) id 1spRaP-0004Bh-6j for emacs-devel@gnu.org; Sat, 14 Sep 2024 14:09:09 +0200 Content-Disposition: inline Original-Received: from [Authenticated alias (1196375)] by runbox.com with http (RMM6); for ; Sat, 14 Sep 2024 12:09:09 GMT X-RMM-Aliasid: 1196375 X-Mailer: RMM6 Received-SPF: pass client-ip=2a0c:5a00:149::25; envelope-from=meedstrom@runbox.eu; helo=mailtransmit04.runbox.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:323610 Archived-At: Previous discussion: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D67955 Currently, the setting of `use-package-vc-prefer-newest` defaults to nil. I want to bring up some problems with that, and suggest fixes. PROBLEM 1. MISMATCH WITH PACKAGE-VC Now use-package :vc is not in line with the behavior of the package-vc-install command, which fetches the newest commit. All other package managers I know of also fetch the newest commit. It is the new use-package :vc which is the odd one out in the ecosystem, and that can cause stability issues, which I go into more deeply on this Reddit comment: https://old.reddit.com/r/emacs/comments/1f8ok7c/do_you_set_packageinstallup= gradebuiltin_to_t/llimwe0/ PROBLEM 2. "LAST RELEASE" CANNOT BE ASSUMED TO BE THE LAST RELEASE I see many packages that have not bumped their Package-Version header for years. Perhaps they bump by git tags, or just stopped bumping versions. I understand them, since it is a lot of manual labor to bump it, cut a release commit, then bump again to append a "-pre" or a ".0.50-git", and to remember to do this everywhere the version string may occur, like in docs. I'm also guessing there's a segment of developers that have sensed that this labor does not end up helping users, so they are not motivated to keep doing it. Versions only work as intended if everyone is versioning regularly, and that is possible to enforce in a curated repo like GNU Elpa or Debian's repackaged Emacs packages, but as soon as you also install packages outside of that repo (and well, most packages are outside), there's no longer any guarantee and in fact the outdated versions in the curated repo are likely to cause breakage. I have personally had to give up on things like ELPA, Melpa Stable, Debian packages etc. It always caused instability. By contrast, installing 200-400 packages off Melpa, in other words the latest dev snapshots, has caused me no issues in ~7 years. So there are two islands of stability: 1. Stay inside a curated repo entirely 2. Leave the curated repo entirely and install only dev snapshots Now consider what use-package :vc is for. It is for installing things OUTSIDE any curated repo. I leave it to you to pick a default setting for `use-package-vc-prefer-newest`. PROBLEM 3. FORCED REPO REWRITES I have been forced to use git-filter-repo to rewrite my package's commit history, to erase all instances of the Package-Version header. That's because I had been content to leave the header permanently at "0.6.0.50-git". If I kept doing that with the new use-package :vc in existence, it would cause users to download a horribly outdated version of my package. If I understand correctly. I foresee one of two things will happen in the future: 1. More and more package authors carry out the same rewrite I did 2. (more likely) Increased instability as package authors do NOT do this rewrite, and users end up with ancient versions all over the place SUGGESTED FIXES A few possibilities: 1. Change `use-package-vc-prefer-newest` to default to t. 2. Change package-vc so when it walks the commit history to find the "last release" or any specific version, it should target the newest commit that has the given Package-Version, not the oldest commit. - That would allow devs to continue having a frozen Package-Version without breaking users' setups. - Of course, this is effectively the same as option 1, but the semantic distinction might be usable in the future to e.g. ignore version strings that have a "-pre" inside. 3. Roll out a strategy for moving the entire community onto the norm of versioning packages prior to distribution, ideally to the extent that Melpa is no longer necessary and can go offline in favor of Melpa Stable. (Until then, Melpa Stable is best avoided: https://old.reddit.com/r/emacs/comments/etikbz/) Obviously difficult, but as I've said, versioning only works if everyone does it. Specifically, it gives us stability if every developer is running the "released version" of most packages other than their own. Currently we have an ecosystem where most developers are running the dev snapshot of most packages, and any half-measures to change this will only destroy the islands of stability that we do currently enjoy. The topic of this email is one such half-measure. 4. Have Emacs ship an automation tool like https://github.com/magit/sisyphus, recommend it everywhere, then have package.el, package-vc and use-package :vc all throw an error on finding more than one commit with a given Package-Version string and refuse to install due to ambiguity. 5. Deprecate the Package-Version header and instead maybe let package.el perform an automatic string substitution from the git/hg tag, if it is still desirable to see the version in the source file. The version could also be substituted into Info docs and other places the version string should occur. - This is effectively a convenient alternative to option 4.