From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Remove version numbers for some built-in packages? Date: Wed, 4 Mar 2020 05:38:36 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="30119"; mail-complaints-to="usenet@ciao.gmane.io" To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 04 05:39:48 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 1j9Loy-0007fI-N4 for ged-emacs-devel@m.gmane-mx.org; Wed, 04 Mar 2020 05:39:48 +0100 Original-Received: from localhost ([::1]:57242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9Lox-0001d4-LT for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Mar 2020 23:39:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51141) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9Lo1-00012X-Uj for emacs-devel@gnu.org; Tue, 03 Mar 2020 23:38:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j9Lo0-0001ti-Mt for emacs-devel@gnu.org; Tue, 03 Mar 2020 23:38:49 -0500 Original-Received: from mail-yw1-f53.google.com ([209.85.161.53]:35775) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j9Lo0-0001sT-J5 for emacs-devel@gnu.org; Tue, 03 Mar 2020 23:38:48 -0500 Original-Received: by mail-yw1-f53.google.com with SMTP id a132so830835ywb.2 for ; Tue, 03 Mar 2020 20:38:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/1kme/BXSWiH/qS+GcRmTUv8jf2JLqJ5lFk1EnSB8GA=; b=AigqQJFjy8/eIvOxUGNHieM5zh4WuOav+j9A5PgCqffCzDc/q2Qw6eMNVucDvaaKW5 5hKs7HxS5u5FfyBSl9nboJFOSfNkN6Kbt6K5jpaAZBZGoBdrbx40hriN+pn3ZPDCoTbE koAh+LA1Poubf/8Vy20ClxY1frepUgagU8UWhgY5r7ljIhZNtfDbbQxSOwGh9lRn3DcX 2/m/HcX7bK73arPVGqGFaT6hLFxo9erieFbIa/2O6xs/KUEHyJQeeMvJ78P77HjxnSWG jGcmGzf/RoSf6leKIOhDicNk8jjCIqPaPNz0pZrUbN/Mq+oWPpukFGw24Z4AxiP0/Xsq APnQ== X-Gm-Message-State: ANhLgQ143GGuhSzVMf8vIcpYo1Nx+ZtzsEQWX5HPCWbkGacE7L1PkYOg 2cu6+XsQPM9Ib0LpwGOhp9VnIRwVnGls99/yr5J6DEvgs98= X-Google-Smtp-Source: ADFU+vvBw8TXTk4BIiCYucidLUYsRR1o1SRQ/GcqBTqcG1fgvCfZmFEns/l8gvxTPCPHb3LFPPMrOfMN/jpeFYFhOAQ= X-Received: by 2002:a81:8606:: with SMTP id w6mr1143531ywf.137.1583296727545; Tue, 03 Mar 2020 20:38:47 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.161.53 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:245210 Archived-At: It seems like the package versions in built-in packages sometimes change very rarely. For example, checkdoc.el has had the same version number since 1998. An extreme example is edmacro.el, which has had the same version number since 1993. Yet if you run M-x finder-by-keyword, the version number will be displayed next to the package name like it actually means something. It seems to me that having no version number in the library would make more sense in these cases. It's part of Emacs and has whatever version Emacs has. Also having no version would clarify which packages might have a more recent version available elsewhere. So speaking of version numbers of built-in packages, which are not available from ELPA or elsewhere, and maintained only in our own tree: 1. Do we need a version number in the header for these cases? 2. Do the 'foobar-version' variables serve any purpose whatsoever (in these cases), or should they just be declared obsolete? Maybe they were useful at one point, but they're hardly useful when the values haven't changed in 15+ years. Some examples of the packages I'm talking about: - checkdoc - delim-col - edmacro - hippie-exp - woman - edt Some examples of packages I'm *not* talking about: - org-mode - cc-mode - ada-mode To be clear, I'm *not* talking about any package available also from ELPA, has an active maintainer to make the decision, or where the version number has changed some time during the previous decade. I would suggest to clean up only the most obvious candidates. Best regards, Stefan Kangas