From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#70647: 30.0.50; When are :core packages released to GNU ELPA? Date: Wed, 01 May 2024 07:29:48 +0000 Message-ID: <87jzke56s3.fsf@posteo.net> References: <87mspcmj1g.fsf@gmail.com> <871q6map91.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35048"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jim Porter , Eli Zaretskii , 70647@debbugs.gnu.org To: No Wayman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 01 09:31:03 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1s24Qh-0008w0-Ip for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 May 2024 09:31:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s24QV-0006Bd-Gs; Wed, 01 May 2024 03:30:51 -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 1s24QL-0006Aw-MR for bug-gnu-emacs@gnu.org; Wed, 01 May 2024 03:30:48 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s24QL-0001b9-98 for bug-gnu-emacs@gnu.org; Wed, 01 May 2024 03:30:41 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s24Qg-0002fA-9L for bug-gnu-emacs@gnu.org; Wed, 01 May 2024 03:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 May 2024 07:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70647 X-GNU-PR-Package: emacs Original-Received: via spool by 70647-submit@debbugs.gnu.org id=B70647.171454861910225 (code B ref 70647); Wed, 01 May 2024 07:31:02 +0000 Original-Received: (at 70647) by debbugs.gnu.org; 1 May 2024 07:30:19 +0000 Original-Received: from localhost ([127.0.0.1]:35899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s24Py-0002er-W9 for submit@debbugs.gnu.org; Wed, 01 May 2024 03:30:19 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:40087) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s24Px-0002eh-10 for 70647@debbugs.gnu.org; Wed, 01 May 2024 03:30:17 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 2FEB4240103 for <70647@debbugs.gnu.org>; Wed, 1 May 2024 09:29:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1714548590; bh=sMGQBCC88PkG9QGNUAxXbSI8Avp7TuCFuaJnpj5HRXk=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=JZIlU33/p3NQT4FRputlwvtKyt8nwXcMm07SChwOu6U+h5wKn995EnFtIUHDTGEME u/bZFc4uMmuHmUtCUYkc2zjUNl5Oz9uowpyuRbGGUHb/kRfP8A+4HRWCe+mrWyjXTm rBNdeWCume2YpMLaYafVossWNgLI7+SvrAcPXfMUVpdbCXnhpvtaux3WeOaNKE1CNw RT0WEjJaihIrEsaCtfMudAj34xFspypFnVnWIShelnhyjFqrEIqGxWVijq6T2VGlEg PI1p3PpDA59Fh+j7aa278weriAFVLEuewupq7uNO7GLFe63VVjcP1F0y8+C40UTbxc dusbOBCDiV08g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VTpcF27mkz6txl; Wed, 1 May 2024 09:29:48 +0200 (CEST) In-Reply-To: <871q6map91.fsf@gmail.com> (No Wayman's message of "Tue, 30 Apr 2024 10:39:38 -0400") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284239 Archived-At: No Wayman writes: > PK> When a commit modifies the Version header in the main file, then > the PK> state of that commit is used to trigger a new release, both > for core and PK> otherwise. > > Where is this documented? In the ELPA README[0]: This cron job only creates a new package when the "version" (as specified in the =Version:= header) of a package is modified. This means that you can safely work on the next version here without worrying about the unstable code making it to GNU ELPA, and simply update the =Version:= when you want to release the new code. [0] https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README > JP> I believe the reason that Eglot's release date is March 31 is > because that's the JP> day that ELPA itself was updated to include > Atom feeds for package updates, JP> which re-published all the > existing packages. See here: JP> > . > > PK> There were issues related to some recent changes that re-build the > PK> package tarballs, but the content should have been the same. But > that PK> was a mistake, and not something that should happen on a > regular basis. > > Thanks to both of you for the clarification. > > This still begs the question of why the publication date is listed > rather than the commit date for the tarball. AFAIK this has historical reasons, that might relate to the old implementation of the ELPA build server. It should be possible to change this now, that all packages have git repositories. > Imagine if when searching for a film on IMDB the results presented the > date the IMDB page was last updated rather than the year the film was > released. e.g. "Ghostbusters (2024-04-15)" for the 1984 film. Not a > perfect analogy, but it makes the point: > The tarball publishing date, if displayed at all, should be secondary to the commit date. I get what you mean, the point is that using the tarball date was just an easy internal hack to avoid having to re-determine the commit date. Setting aside issues like those mentioned above, it works well enough. -- Philip Kaludercic on peregrine