* bug#70647: 30.0.50; When are :core packages released to GNU ELPA?
@ 2024-04-29 12:48 No Wayman
2024-04-29 13:17 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: No Wayman @ 2024-04-29 12:48 UTC (permalink / raw)
To: 70647
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#70647: 30.0.50; When are :core packages released to GNU ELPA?
2024-04-29 12:48 bug#70647: 30.0.50; When are :core packages released to GNU ELPA? No Wayman
@ 2024-04-29 13:17 ` Eli Zaretskii
[not found] ` <87y18wxoll.fsf@gmail.com>
2024-04-29 18:16 ` Jim Porter
2024-04-30 14:39 ` No Wayman
2 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-04-29 13:17 UTC (permalink / raw)
To: No Wayman; +Cc: 70647
> 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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#70647: 30.0.50; When are :core packages released to GNU ELPA?
2024-04-29 12:48 bug#70647: 30.0.50; When are :core packages released to GNU ELPA? No Wayman
2024-04-29 13:17 ` Eli Zaretskii
@ 2024-04-29 18:16 ` Jim Porter
2024-04-30 14:39 ` No Wayman
2 siblings, 0 replies; 7+ messages in thread
From: Jim Porter @ 2024-04-29 18:16 UTC (permalink / raw)
To: No Wayman, 70647
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>.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#70647: 30.0.50; When are :core packages released to GNU ELPA?
2024-04-29 12:48 bug#70647: 30.0.50; When are :core packages released to GNU ELPA? No Wayman
2024-04-29 13:17 ` Eli Zaretskii
2024-04-29 18:16 ` Jim Porter
@ 2024-04-30 14:39 ` No Wayman
2024-05-01 7:29 ` Philip Kaludercic
2 siblings, 1 reply; 7+ messages in thread
From: No Wayman @ 2024-04-30 14:39 UTC (permalink / raw)
To: 70647; +Cc: Jim Porter, Philip Kaludercic, Eli Zaretskii
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#70647: 30.0.50; When are :core packages released to GNU ELPA?
2024-04-30 14:39 ` No Wayman
@ 2024-05-01 7:29 ` Philip Kaludercic
0 siblings, 0 replies; 7+ messages in thread
From: Philip Kaludercic @ 2024-05-01 7:29 UTC (permalink / raw)
To: No Wayman; +Cc: Jim Porter, Eli Zaretskii, 70647
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-05-01 7:29 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-29 12:48 bug#70647: 30.0.50; When are :core packages released to GNU ELPA? No Wayman
2024-04-29 13:17 ` Eli Zaretskii
[not found] ` <87y18wxoll.fsf@gmail.com>
[not found] ` <86sez4qndc.fsf@gnu.org>
[not found] ` <87cyq8dz4h.fsf@gmail.com>
2024-04-29 14:35 ` Eli Zaretskii
2024-04-29 17:55 ` Philip Kaludercic
2024-04-29 18:16 ` Jim Porter
2024-04-30 14:39 ` No Wayman
2024-05-01 7:29 ` Philip Kaludercic
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.