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
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
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
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
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
> 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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
+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
31 matches
Mail list logo
