From: Bastien <bzg@gnu.org>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-orgmode@gnu.org
Subject: Re: Release 9.1.12
Date: Fri, 27 Apr 2018 15:42:44 +0200 [thread overview]
Message-ID: <87fu3gbwa3.fsf@gnu.org> (raw)
In-Reply-To: <871sf0x0c1.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Fri, 27 Apr 2018 15:09:34 +0200")
Hi Nicolas,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Bastien <bzg@gnu.org> writes:
>
>> Speaking of which... IIRC one of the reasons for not having
>>
>> (defconst org-version "9.1.12")
>>
>> in org.el was to having merge conflicts.
^^^^^^
sorry for the typo: s/having/avoid
> I don't remember this issue.
In the early days, org.el contained something like
(defconst org-version "6.53") to declare Org version.
Then Achim helped us produce org-version.el by using
Makefile, inferring Org version from Git tags.
This led to users being confused by not understanding
why their Org version was another one than the one they
downloaded or cloned - because they didn't use Make to
create org-version.el.
While trying to understand why it was so bad to have
(defconst org-version "6.53") in org.el, the answers
I receive (IIRC) were that it's bad practise to store
the version number in the file, it leads to merge
conflicts when merging from a version (eg "9.1.11"
in maint) to another say (eg "9.2rc1" in master).
I've never been convinced it was a real issue.
>> Does having "Version: 9.1.12" in org.el means we can switch back
>> to having (defconst org-version "9.1.12") there as well?
>>
>> Could it fix the very annoying "I-don't-know-what-Org-version-is
>> running-within-my-Emacs" issue?
>>
>> I'm aware that M-x org-version RET is more informative today,
>> but I also see just too many people struggling with the current
>> way of setting the version.
>
> I don't understand what you mean by "setting the version". I probably do
> not understand the problem you are describing to its full extent, but
> I think Version: keyword (necessary for ELPA) and `org-version' are
> enough. Yet another way to defined the Org version would be asking for
> trouble.
Sure keyword (necessary for ELPA) and `org-version' are enough.
I'm not asking for yet another way to define the Org version,
I'm wondering whether we can revert back to the primitive way
of doing things: set (defconst org-version "9.2") in org.el,
instead of creating a separate org-version.el thru Make.
Not an issue for now, of course. Probably Achim can chime in
and, if he has the patience, re-explain me why the primitive way
is wrong, even if Version: 9.2 is written down in org.el.
--
Bastien
prev parent reply other threads:[~2018-04-27 13:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-27 8:49 Release 9.1.12 Bastien
2018-04-27 9:10 ` Nicolas Goaziou
2018-04-27 10:39 ` Bastien
2018-04-27 13:09 ` Nicolas Goaziou
2018-04-27 13:42 ` Bastien [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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=87fu3gbwa3.fsf@gnu.org \
--to=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).