GNU bug report logs - #70647
30.0.50; When are :core packages released to GNU ELPA?

Previous Next

Full log

View this message in rfc822 format

From: Philip Kaludercic <philipk <at> posteo.net>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: Jim Porter <jporterbugs <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 70647 <at> debbugs.gnu.org
Subject: bug#70647: 30.0.50; When are :core packages released to GNU ELPA?
Date: Wed, 01 May 2024 07:29:48 +0000

No Wayman <iarchivedmywholelife <at> gmail.com> 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>
> <https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00777.html>.
>
> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.