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: GNU ELPA package proposal: visual-fill-column Date: Tue, 26 Oct 2021 11:20:54 -0400 Message-ID: References: <87k0i0w39l.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27276"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Joost Kremers , Emacs developers To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 26 17:29:45 2021 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 1mfOOW-0006sa-Jc for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 17:29:44 +0200 Original-Received: from localhost ([::1]:34834 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfOOV-00075M-FI for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 11:29:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47088) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfOHI-0001J4-Bt for emacs-devel@gnu.org; Tue, 26 Oct 2021 11:22:16 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23069) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfOHF-0007Aj-2t for emacs-devel@gnu.org; Tue, 26 Oct 2021 11:22:14 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D824D440AFD; Tue, 26 Oct 2021 11:22:09 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8B3354409BE; Tue, 26 Oct 2021 11:22:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1635261728; bh=fMt/kZoENO+6fgwuwpjMrSBRFsyQdlPgRN6NqoQqvmM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=pxmBcWP7zgXQZM6tVch9sjFl8wrfccqvQHGoNfFq29Y82lc/wJwOO6aWW9y4Pz6IV Qywqadhhd4H8B9VIYeLJGoZ9IN+INLgbuoCuZhi9lhj+Kl8N62KQerVW3z0RsOOtbF +823hKYLh+yZOLLtIMIPzXV8qbnYA7KJCE6QsyZRZlZUoR0mtSI/N1ehHqyN7K2O78 1pyg6KcOzuixACLAI1MtUzTo5/fpIqOn5D529s2CW5T269Lo6GdoKpQ0laNQhic30+ jBLrUZ2GNt4s6EAzgu007o4RCYCLCluphKzMwRNdjlCETV06dB1R5RL+WvEwo6Qj7W HK7fRt3ADk8rQ== Original-Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 319941201CF; Tue, 26 Oct 2021 11:22:08 -0400 (EDT) In-Reply-To: (Stefan Kangas's message of "Tue, 26 Oct 2021 17:17:16 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca 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:277876 Archived-At: Stefan Kangas [2021-10-26 17:17:16] wrote: > Stefan Monnier writes: >> No, `package.el` is not smart enough. The reason is that the version >> numbers used by MELPA don't match the ones used in GNU ELPA, so the >> MELPA versions always seem to be "much higher" than the ones in GNU ELPA >> (e.g. 20180223.223 > 5.7.2). > Maybe we should fix that. Could it be as easy as looking for version > numbers starting with "YYYYMMDD", and if there is no package available > with a version formatted that way, just assume that the currently > highest numbered "normally versioned" package is more recent? Assuming would definitely not be a good idea because scenarios where this is a bad idea aren't sufficiently hypothetical, IMO. But we could add a hack that would detect such cases are prompt the user. Better if we could get the release date of the package version 5.7.2 ;-) Stefan