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

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

[No Wayman]

As I understand it, GNU ELPA releases packages when a commit 
changes the Version package header. GNU-devel ELPA is a rolling 
release. How about "core" packages? For example, the eglot version 
bundled with Emacs 29.3 is at Version 1.12.xx. The latest version 
on GNU ELPA is 1.17, released on 3/31/2024, but git points to 
commit "b014bca833a" on 1/25/2024 as responsible for bumping the 
version to 1.17.

Is all of this documented somewhere?

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

[Eli Zaretskii]

> From: No Wayman <iarchivedmywholelife@gmail.com>
> Date: Mon, 29 Apr 2024 08:48:27 -0400
> 
> 
> As I understand it, GNU ELPA releases packages when a commit 
> changes the Version package header. GNU-devel ELPA is a rolling 
> release. How about "core" packages? For example, the eglot version 
> bundled with Emacs 29.3 is at Version 1.12.xx. The latest version 
> on GNU ELPA is 1.17, released on 3/31/2024, but git points to 
> commit "b014bca833a" on 1/25/2024 as responsible for bumping the 
> version to 1.17.

Are there any differences in the code between version 1.17 on ELPA and
the Eglot code as of commit b014bca833a.

> Is all of this documented somewhere?

What would you like to be documented?

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

[Eli Zaretskii]

> From: No Wayman <iarchivedmywholelife@gmail.com>
> Cc: Philip Kaludercic <philipk@posteo.net>
> Date: Mon, 29 Apr 2024 10:25:50 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes: 
>  
> > [Why private email?]
> 
> Apologies. Must've fat-fingered my reply key binding. 

Looks like you did it again.  Please use Reply All, to have the bug
tracker CC'ed.

Resending to the bug tracker.

> >> From: No Wayman <iarchivedmywholelife@gmail.com> Date: Mon, 29 
> >> Apr 2024 09:52:54 -0400  Eli Zaretskii <eliz@gnu.org> writes:  
> >>   
> >> > Are there any differences in the code between version 1.17 on 
> >> > ELPA and the Eglot code as of commit b014bca833a. 
> >>  I would hope not. Otherwise the version information is 
> >> incorrect. 
> > 
> > Then why is this a problem?  File time stamps are immaterial 
> > with modern VCSes.
> 
> The problem is it's confusing.
> When is the "release date" of eglot 1.17?
> The date of the commit which bumped the Version header?
> The date of some other action which triggered an ELPA build?
> If file timestamps are indeed immaterial, than it would make the 
> most sense to stick with the commit date which bumped the Version 
> header.
> That does not appear to be the case.
>   
> >> > What would you like to be documented? 
> >>  - What triggers a package build/release on GNU ELPA in all 
> >> cases  
> >>   (:core or otherwise)? 
> > 
> > Philip will tell, but I'm not surprised, given that this is a 
> > volunteer project. 
> > 
> >> - What triggers a package build/release on GNU-devel ELPA. 
> > 
> > What is "GNU-devel ELPA"?
> 
> Forgive me if I misspoke, but: https://elpa.gnu.org/devel/
> 
> > <h1> GNU-devel ELPA Packages </h1>
> 
> If that's not what it's called, then the website should be updated 
> to reflect the preferred name.
>  
> > I don't even understand the problem you see here. 
> 
> I've seen other package maintainers confused about what/when a 
> rebuild is triggered. I have reports on Elpaca's issue tracker 
> where users are confused by the release dates listed on GNU ELPA's 
> websites. I myself am not 100% sure I understand all cases that 
> trigger builds. The issue is I could not find a place where this 
> is all clearly documented.
> 

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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: No Wayman <iarchivedmywholelife@gmail.com>
>> Cc: Philip Kaludercic <philipk@posteo.net>
>> Date: Mon, 29 Apr 2024 10:25:50 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes: 
>>  
>> > [Why private email?]
>> 
>> Apologies. Must've fat-fingered my reply key binding. 
>
> Looks like you did it again.  Please use Reply All, to have the bug
> tracker CC'ed.
>
> Resending to the bug tracker.
>
>> >> From: No Wayman <iarchivedmywholelife@gmail.com> Date: Mon, 29 
>> >> Apr 2024 09:52:54 -0400  Eli Zaretskii <eliz@gnu.org> writes:  
>> >>   
>> >> > Are there any differences in the code between version 1.17 on 
>> >> > ELPA and the Eglot code as of commit b014bca833a. 
>> >>  I would hope not. Otherwise the version information is 
>> >> incorrect. 
>> > 
>> > Then why is this a problem?  File time stamps are immaterial 
>> > with modern VCSes.
>> 
>> The problem is it's confusing.
>> When is the "release date" of eglot 1.17?
>> The date of the commit which bumped the Version header?
>> The date of some other action which triggered an ELPA build?
>> If file timestamps are indeed immaterial, than it would make the 
>> most sense to stick with the commit date which bumped the Version 
>> header.
>> That does not appear to be the case.
>>   
>> >> > What would you like to be documented? 
>> >>  - What triggers a package build/release on GNU ELPA in all 
>> >> cases  
>> >>   (:core or otherwise)? 
>> > 
>> > Philip will tell, but I'm not surprised, given that this is a 
>> > volunteer project. 

When a commit modifies the Version header in the main file, then the
state of that commit is used to trigger a new release, both for core and
otherwise.

>> >> - What triggers a package build/release on GNU-devel ELPA. 
>> > 
>> > What is "GNU-devel ELPA"?
>> 
>> Forgive me if I misspoke, but: https://elpa.gnu.org/devel/

These are rebuilt on every commit.  The intended audience IMO are
developers here though, so that they can easily preview the state of
packages.

>> > <h1> GNU-devel ELPA Packages </h1>
>> 
>> If that's not what it's called, then the website should be updated 
>> to reflect the preferred name.

The name is fine.  I am just guessing that it is not something that Eli
has to deal with that often.

>> > I don't even understand the problem you see here. 
>> 
>> I've seen other package maintainers confused about what/when a 
>> rebuild is triggered. I have reports on Elpaca's issue tracker 
>> where users are confused by the release dates listed on GNU ELPA's 
>> websites. I myself am not 100% sure I understand all cases that 
>> trigger builds. The issue is I could not find a place where this 
>> is all clearly documented.

There were issues related to some recent changes that re-build the
package tarballs, but the content should have been the same.  But that
was a mistake, and not something that should happen on a regular basis.

-- 
	Philip Kaludercic on peregrine

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

[Jim Porter]

On 4/29/2024 5:48 AM, No Wayman wrote:
> As I understand it, GNU ELPA releases packages when a commit changes the 
> Version package header. GNU-devel ELPA is a rolling release. How about 
> "core" packages? For example, the eglot version bundled with Emacs 29.3 
> is at Version 1.12.xx. The latest version on GNU ELPA is 1.17, released 
> on 3/31/2024, but git points to commit "b014bca833a" on 1/25/2024 as 
> responsible for bumping the version to 1.17.

I believe the reason that Eglot's release date is March 31 is because 
that's the day that ELPA itself was updated to include Atom feeds for 
package updates, which re-published all the existing packages. See here: 
<https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00777.html>.

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

[No Wayman]

 
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?
 
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.
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.

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

[Philip Kaludercic]

No Wayman <iarchivedmywholelife@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