Ihor Radchenko writes:
> Sounds reasonable, though we might emphasize a bit more that it is
> relevant to the latest Org from ELPA/git.
>
> We have
>
>If, for one reason or another, you want to install Org on top of this
> pre-packaged version, you can use the Emacs package system or
Bastien writes:
> Ihor Radchenko writes:
>
>> Should we document this workflow in
>> https://orgmode.org/worg/org-maintenance.html ?
>
> I slightly updated the page again, let me know if it's clear:
> https://orgmode.org/worg/org-maintenance.html
Thanks! LGTM!
>> Maybe we can add this informat
Ihor Radchenko writes:
> Should we document this workflow in
> https://orgmode.org/worg/org-maintenance.html ?
I slightly updated the page again, let me know if it's clear:
https://orgmode.org/worg/org-maintenance.html
>>> If you are running an unsupported
>>> versions, either you should avoid
Samuel Wales writes:
> tim cross, i would like to ask politely for you personally to
> henceforth please be VERY VERY careful when you say that i said or
> wanted something or tried to do something. i am not referring to this
> thread but general espeially in another thread.
BTW, just for th
Samuel Wales writes:
> tim cross, i would like to ask politely for you personally to
> henceforth please be VERY VERY careful when you say that i said or
> wanted something or tried to do something. i am not referring to this
> thread but general espeially in another thread.
apologies if I've
tim cross, i would like to ask politely for you personally to
henceforth please be VERY VERY careful when you say that i said or
wanted something or tried to do something. i am not referring to this
thread but general espeially in another thread.
Tom Gillespie writes:
>
> As mentioned above, I also like this approach. We could create a hack
> to work around the missing package metadata field, which would cause
> a failure when trying to build on emacs < 26 unless org-i-know-what-i-am-doing
> or some such is non-nil. The error message wo
Bastien writes:
> Tim Cross writes:
>
>> Therefore, I think the position should be that once an emacs version is
>> no longer one of the supported versions (current stable Emacs release
>> plus two previous major versions), there is no guarantee we will inform
>> the list when compatibility is l
> The manual actually says
>
> "If this exists, it names packages on which the current package
> depends for proper operation."
>
> so I think it is reasonable to only list the minimum supported Emacs
> version, not the minimum version where it partially or fully works, but
> is not supported.
Tom Gillespie writes:
>> Please, keep ";; Package-Requires: " version in org.el consistent with
>> such statement (Should it be updated for the bugfix branch as well?).
>
> Unfortunately it is not clear that this is the right thing to do because
> nearly every feature of org may work on old ver
> Please, keep ";; Package-Requires: " version in org.el consistent with
> such statement (Should it be updated for the bugfix branch as well?).
Unfortunately it is not clear that this is the right thing to do because
nearly every feature of org may work on old versions. Should we put
users throug
Max Nikulin writes:
> On 08/08/2022 22:46, Bastien wrote:
>> Ihor Radchenko writes:
>>
>>> Could you please elaborate on how exactly we can determine if a
>>> commit changes the compatibility status?
>> Today, we are interested in knowing whether Org is compatible with
>> Emacs 28.1, Emacs 27.
On 08/08/2022 22:46, Bastien wrote:
Ihor Radchenko writes:
Could you please elaborate on how exactly we can determine if a
commit changes the compatibility status?
Today, we are interested in knowing whether Org is compatible with
Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1.
Please, keep ";
Hi Tim,
thanks for reminding me the context.
Tim Cross writes:
> Therefore, I think the position should be that once an emacs version is
> no longer one of the supported versions (current stable Emacs release
> plus two previous major versions), there is no guarantee we will inform
> the list w
Hi Bastien,
all you wrote is fine IMO. However, I think Ihor's point was mainly in
response to the request that we notify the list when compatibility is
going to be lost and that when it comes to versions less than the
currently maintained versions, this isn't really possible.
To put it in more c
Hi Ihor,
Ihor Radchenko writes:
> Could you please elaborate on how exactly we can determine if a
> commit changes the compatibility status?
Today, we are interested in knowing whether Org is compatible with
Emacs 28.1, Emacs 27.1 and Emacs Emacs 26.1.
Ideally, this means maintainers run the t
Bastien Guerry writes:
> If the current release is de facto compatible with older Emacsen and
> a new release will change this, yes, let's announce it in the release
> notes.
>
> We can also send an email to the list using the "X-Woof-Change" to
> announce this upcoming change for the upcoming re
great! one of the things i like about org is the close attention to
user-oriented nature of maintenance. everything on mailing list,
maint branch, compilation warnings few, etc. this is more of the same
user-oriented goodness.
i have noticed an impressive amount of bug fixing, code improvement,
Hi Ihor and Samuel,
Ihor Radchenko writes:
> In addition, we might also announce the oldest supported Emacs version
> in https://orgmode.org/Changes.html.
The current release of Org is meant to be compatible with the last
three major releases of Emacs. That is, as of now, 28, 27, 26.
See http
Stefan Kangas writes:
> Thanks, please find attached an updated patch.
Applied onto main via 0ed0dea22.
Best,
Ihor
your opinion is noted. mine remains, but maintainers are welcome to
do as they think is right. i stated what i thoguht might be useful
for my ase. no further discussion needed.
On 6/30/22, Tim Cross wrote:
>
> Samuel Wales writes:
>
>> i use git version, not elpa, so for me, mailing list coul
Samuel Wales writes:
> i use git version, not elpa, so for me, mailing list could tip me off
> as early as possible, but not too early, if it said in email subject
> header line that in a known upcoming release, it has been decided that
> a specified emacs version will no longer be supported [n
i use git version, not elpa, so for me, mailing list could tip me off
as early as possible, but not too early, if it said in email subject
header line that in a known upcoming release, it has been decided that
a specified emacs version will no longer be supported [note: i presume
and hope this woul
Samuel Wales writes:
> idk about others, but as a luddite follower of bugfix/maint, if
> poissible and not too annoying to do, i would be interested in
> knowing, at the email subject header level, that the upcoming
> bugfix/maint release [state org version number] will not support <=
> [state em
idk about others, but as a luddite follower of bugfix/maint, if
poissible and not too annoying to do, i would be interested in
knowing, at the email subject header level, that the upcoming
bugfix/maint release [state org version number] will not support <=
[state emacs version number] so that i can
Max Nikulin writes:
> On 30/06/2022 18:19, Stefan Kangas wrote:
>> The attached patch deletes some Emacs 24 compat code. Org mode
>> supports Emacs 26 or later, according to:
>> https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
>
> I have no particular opinion to which degree old
On 30/06/2022 18:19, Stefan Kangas wrote:
The attached patch deletes some Emacs 24 compat code. Org mode
supports Emacs 26 or later, according to:
https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
I have no particular opinion to which degree older Emacs versions should
be supp
tch.
From aa0637c22ff1465a19d4007f1e9d16cc0df9972c Mon Sep 17 00:00:00 2001
From: Stefan Kangas
Date: Thu, 30 Jun 2022 13:06:21 +0200
Subject: [PATCH] Delete some Emacs 24 compat code
Org mode supports Emacs 26 or newer:
https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
* lisp/org-compat.el (org-set-transient-
Ihor Radchenko writes:
>> ;;; Integration with and fixes for other packages
>> diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el
>> index 88072852d..287686c01 100644
>> --- a/lisp/org-fold-core.el
>> +++ b/lisp/org-fold-core.el
>> ...
>> +(define-obsolete-function-alias 'org-fold-core--
Stefan Kangas writes:
> The attached patch deletes some Emacs 24 compat code. Org mode
> supports Emacs 26 or later, according to:
> https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
Thanks! I have some comments.
> ;;; Integration with and fixes for other packages
> diff --git
+0200
Subject: [PATCH] Delete some Emacs 24 compat code
Org mode supports Emacs 26 or newer:
https://orgmode.org/worg/org-maintenance.html#emacs-compatibility
* lisp/org-compat.el (org-set-transient-map)
(org-font-lock-ensure): Delete compat aliases. Update callers.
(org-define-error): Redefine as
31 matches
Mail list logo
