GNU bug report logs -
#70647
30.0.50; When are :core packages released to GNU ELPA?
Previous Next
To reply to this bug, email your comments to 70647 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70647; Package
emacs.
(Mon, 29 Apr 2024 12:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
No Wayman <iarchivedmywholelife <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 29 Apr 2024 12:50:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70647; Package
emacs.
(Mon, 29 Apr 2024 13:18:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 70647 <at> debbugs.gnu.org (full text, mbox):
> From: No Wayman <iarchivedmywholelife <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70647; Package
emacs.
(Mon, 29 Apr 2024 14:37:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 70647 <at> debbugs.gnu.org (full text, mbox):
> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: Philip Kaludercic <philipk <at> posteo.net>
> Date: Mon, 29 Apr 2024 10:25:50 -0400
>
> Eli Zaretskii <eliz <at> 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 <at> gmail.com> Date: Mon, 29
> >> Apr 2024 09:52:54 -0400 Eli Zaretskii <eliz <at> 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.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70647; Package
emacs.
(Mon, 29 Apr 2024 17:57:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 70647 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: No Wayman <iarchivedmywholelife <at> gmail.com>
>> Cc: Philip Kaludercic <philipk <at> posteo.net>
>> Date: Mon, 29 Apr 2024 10:25:50 -0400
>>
>> Eli Zaretskii <eliz <at> 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 <at> gmail.com> Date: Mon, 29
>> >> Apr 2024 09:52:54 -0400 Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70647; Package
emacs.
(Mon, 29 Apr 2024 18:17:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 70647 <at> debbugs.gnu.org (full text, mbox):
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>.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70647; Package
emacs.
(Tue, 30 Apr 2024 14:41:01 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70647; Package
emacs.
(Wed, 01 May 2024 07:31:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 70647 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.