emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Kyle Meyer <kyle@kyleam.com>
To: No Wayman <iarchivedmywholelife@gmail.com>
Cc: wtd@pobox.com, marcowahlsoft@gmail.com, emacs-orgmode@gnu.org,
Subject: Re: Switching to new Git repositories
Date: Thu, 23 Sep 2021 18:24:19 -0400	[thread overview]
Message-ID: <87a6k33p7w.fsf@kyleam.com> (raw)
In-Reply-To: <87y27nt29u.fsf@gmail.com>

On 09/23/21 17:17:48 -0400, No Wayman wrote:
>> Sounds like a weird issue.  I don't think this 9.5-dev tag is 
>> something from the Org repo.
> There is a bug in mk/targets.mk introduced by 61336f80dc.

Quoting that commit message for context:

  mk/targets.mk: Add version fallback for tag-less repos
  * mk/targets.mk (ORGVERSION, GITVERSION): Get version from lisp/org.el
  header if it can't be retrieved from git-describe.
  As of elpa.git's ee03829f90 (Finalize the new master branch,
  2020-12-14), org-release and org-git-version are empty strings in
  https://elpa.gnu.org/packages/org-*.tar files.  This is because the
  new setup executes `make autoloads info' in an elpa.git worktree with
  an Org branch checked out, but elpa.git of course doesn't have Org's
  release tags.
  Maintaining the org.el version header has been a point of contention
  in the past [1], but the header has been there for a while now.  Use
  it to avoid the above elpa.git issue.  In the case of the master
  branch, the org-release value generated in a tag-less repo will have a
  different version than the one from a regular repo because org.el's
  version header has a "-dev" suffix, but that's still better than an
  empty version.

> As others have pointed out, the new repository does not have tags.
> As a fallback, org.el's version is read in it's header.
> However, it looks like Kyle forgot to trim that string so we get 
> ORGVERSION set to "9.5-dev" instead of "9.5".

I of course can't say for sure, but based on my commit message (in
particular the last paragraph), it sounds like I was aware of the
discrepancy but didn't realize it'd cause the downstream "Invalid
version syntax" issue mentioned by Bill in

> This causes `org-version' to return an incorrect version string.
> The attached patch addresses the issue in the makefile.


> Subject: [PATCH] mk/targets.mk: Fix ORGVERSION in tag-less repos
> * mk/targets.mk (ORGVERSION, GITVERSION): properly generate ORGVERSION.

I think it'd be better to say something more specific about the change
rather than say "properly" and assume the reader knows what the writer
has in mind.

> Fix bug introduced 61336f80 which caused ORGVERSION to be generated as
> "Major.Minor-dev" instead of "Major.Minor" in tag-less repos.

Please say what the bug is.  Can you give a sparse outline of the call
chain for the error mentioned in Bill's message?

> -    ORGVERSION := $(shell $(BATCH) --eval "(require 'lisp-mnt)" \
> -      --visit lisp/org.el --eval '(princ (lm-header "version"))')
> -    GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
> +    ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \
> +      --visit lisp/org.el --eval '(princ (lm-header "version"))'))
> +    GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD))

It looks like you've unintentionally added a ')' to the end of the

Another approach would be to update org.el's version to contain
something that still signals "-dev" but won't trigger the "Invalid
version syntax" (which, based on grepping the Emacs repo, is signaled by
version-to-list).  But given that in the current setup a clone with tags
wouldn't use the header version, stripping -dev for consistency sounds
like the way to go.

  reply	other threads:[~2021-09-23 22:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20  4:37 Switching to new Git repositories Bastien
2021-09-20  9:08 ` Marco Wahl
2021-09-20  9:16   ` Timothy
     [not found]     ` <87ilyvtwma.fsf@gnu.org>
2021-09-20 10:30       ` Marco Wahl
2021-09-25 13:50         ` Bastien
2021-09-20  9:27   ` Bastien
2021-09-20 10:14     ` Eric S Fraga
2021-09-20 10:20       ` Bastien
2021-09-20 10:38         ` Eric S Fraga
2021-09-23 10:07 ` Éibhear
2021-09-23 15:17   ` Nick Dokos
2021-09-23 17:40     ` Colin Baxter
2021-09-23 18:54       ` Marco Wahl
2021-09-23 18:06   ` William Denton
2021-09-23 18:23     ` Éibhear
2021-09-23 19:05       ` Colin Baxter
2021-09-23 19:07     ` Marco Wahl
2021-09-23 21:17       ` No Wayman
2021-09-23 22:24         ` Kyle Meyer [this message]
2021-09-23 23:13           ` No Wayman
2021-09-24  1:48             ` Kyle Meyer
2021-09-24  3:21         ` William Denton
2021-09-24  7:50     ` Eric S Fraga
2021-09-25 14:57   ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a6k33p7w.fsf@kyleam.com \
    --to=kyle@kyleam.com \
    --cc=eibhear.geo@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=iarchivedmywholelife@gmail.com \
    --cc=marcowahlsoft@gmail.com \
    --cc=wtd@pobox.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).