Re: [PATCH] Delete some Emacs 24 compat code
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 clone > Org’s git repository. > > Adding the information that Org from ELPA/git is only compatible with > certain Emacs versions is important. I tried something in https://git.sr.ht/~bzg/org-mode/commit/b428839f but feel free to enhance the wording if needed. -- Bastien
Re: [PATCH] Delete some Emacs 24 compat code
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 information to the manual in the Installation >> section? > > Yes, maybe just one sentence regarding Emacs compatibility like > > "Org releases are compatible with the latest three major Emacs > releases." > > with a footnote pointing to > https://orgmode.org/worg/org-maintenance.html 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 clone Org’s git repository. Adding the information that Org from ELPA/git is only compatible with certain Emacs versions is important. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] Delete some Emacs 24 compat code
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 updates or be prepared for breakage >>> without warning. When we do know a commit has broken compatibility, that >>> information will be relayed to the list, but we cannot guarantee we can >>> provide such information at the time the change is committed. Running an >>> unsupported versions is at your own risk. >> >> Yes, thanks for articulating this very clearly. > > Maybe we can add this information to the manual in the Installation > section? Yes, maybe just one sentence regarding Emacs compatibility like "Org releases are compatible with the latest three major Emacs releases." with a footnote pointing to https://orgmode.org/worg/org-maintenance.html Thanks, -- Bastien
Re: [PATCH] Delete some Emacs 24 compat code
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 the record, what I was referring to were the two posts where you wrote > 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 prepare at my glacial > luddite pace. this is probably already done, but making it prominent > beforehand might help signal the need for changes with lots of time or > simplify git stuff [e.g. pull soon as the last pull and make a note > not to pull after that, which prevents the need for figuring out > rebasing again]. and in particular > 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 would not occur in just a plain git update for such a > thing but would get a release that gets noted in email and get that > advance notice], > then upon seeig such email i can stop pulling from git until i am able > to upgrade emacs. [lots of stuff takes lots and lots of time for me > in my case] idk if practical, but just saying what seems like it > would be useful to me. > i would then stay at something reasonably close to the first release > that does not support that version fo emacs. and the only point I wanted to make is that this isn't practical because we don't always know when a patch removes compatibility for a non-supported version of Emacs (i.e. major version four or more versions behind current major version). The other point to note is that git commits are not releases and commits happen before releases. So, while an org release does specify precisely which Emacs versions are supported, commits occur in-between releases. Supported versions don't change during those commits, but support for older unsupported versions of emacs could be lost at any commit and as we don't test against those older versions, we won't know until someone reports it later. At the end of the day, if your running org in an Emacs version which is four or more major versions behind the current stable release, you are at risk of breakage at any update and this is likely to happen without notice (if you update often, you are likely to be the first person to discover the loss of compatibility). Good news is, as your running from git, it is trivial to revert back to an earlier version. Something which ELPA users cannot do.
Re: [PATCH] Delete some Emacs 24 compat code
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 caused some form of offence - definitely not my intention. However, I'm not sure what other thread your referring to. As far as I can recall, this is the only thread I've mention you by name.
Re: [PATCH] Delete some Emacs 24 compat code
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.
Re: [PATCH] Delete some Emacs 24 compat code
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 would say something along > the lines of "this version of org {org-version} will run on {emacs-version}" > but it is not supported. If you still want to install it, please run > (setq org-i-know-what-i-am-doing t) and then install the package again" > or something like that. > What I don't like with this approach is that I think it is making everything far too complicated. The other issue at the core of this is that we don't always know if it actually does run on an unsupported version as no testing is done against those earlier versions. We would have to have a message like "It may or may not work on this unsupported version of emacs, run at your own risk." Personally, I would just keep it far simpler. Anyone running a version of Emacs which is 4 major versions behind the current stable release should expect problems and challewnges if they also want to run the latest versions of packages under a version that old . When that out of datge, I think it is reasonable to expect that if you want to install the latest version, you will need to do it manually and not via package.el. I don't think we have the resources for anything more complicated. We state what versions it is supported on and leave it at that. When we say supported, we can extgend that to mean able to be installed via package.el. Recall where all this started. Samuel wanted to be able to run Org on a unsupported version of Emacs and for there to be a message or some sort of alert once org no longer runs under that version of Emacs. Unfortunately, with a package a large and complex as org, defining what no longer runs means is difficult because that will largely depend on which features you rely on. The other problem is we don't test against unsupported versions, so we only know when a feature/facility no longer works once someone reports it. Even then, it may not be straight-forward as the feature/function may only be broken in some configuration scenarios. I do like the idea of having the bug reporting functionality check whether the version being used is a supported version and alerting the user when it isn't. Otherwise, I think keep it very simple. Make it clear what is supported and only enable it to be installedl via package.el on versions of Emacs which are in the supported version list. Anyone outside that list can either stick with the version they have installed (no updates), manually install and run the risk or plan to update Emacs to a supported version. At the end of the day, we are not forcing anyone to upgrade. They can continue to use the version they have running under Emacs 25 for as long as they want. Obviously, it won't get bug fixes etc, but that is what unsupported means. I suspect most people would rather have package.el tell them that their Emacs version is not supported than have it silently do the update and then find some feature they rely on no longer works (especially as downgrading a package to an earlier versions isn't something package.el supports). .
Re: [PATCH] Delete some Emacs 24 compat code
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 lost. > > Yes, fully agreed. If my previous message was unclear: it is *good* > to inform the list of any compatibility issue (with any Emacsen), but > we cannot promise we will warn the list for every breakage as we don't > test Org with Emacs <=25. Should we document this workflow in https://orgmode.org/worg/org-maintenance.html ? >> If you are running an unsupported >> versions, either you should avoid updates or be prepared for breakage >> without warning. When we do know a commit has broken compatibility, that >> information will be relayed to the list, but we cannot guarantee we can >> provide such information at the time the change is committed. Running an >> unsupported versions is at your own risk. > > Yes, thanks for articulating this very clearly. Maybe we can add this information to the manual in the Installation section? -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] Delete some Emacs 24 compat code
> 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. The weasel words here are "proper operation" because it covers everything from "will byte compile without errors (but maybe with warnings)" to "has zero bugs and will never fail under any circumstances." My interpretation is that Package-Requires means "will byte compile without errors" because all software has bugs. Unfortunately package metadata doesn't seem to have another field for something like Package-Supported-Version. > Problem I see with your approach is there will be an expectation that if > it lists Emacs 25.x that it works under that version and anything which > doesn't work is a bug. People will not check this list, README or NEWS > files to verify what version of Emacs is compatible with - if they can > use package.el to install it, they will expect that it works without any > issues and any encountered are either a configuration error or a bug. I agree that this is an issue. I think the easiest solution would be to add something to org-submit-bug-report which would inform the user that they are running a version of org that is too new for their version of emacs and is thus unsupported. Another solution would be for package metadata to deconflate "will immediately fail if you try to run this on old versions" from "only make this update available to users running emacs at or above this version." I think this is a variant of your suggestion to make upgrading to unsupported versions more difficult but not impossible. > Even worse, once a problem with (for example) Emacs 25.x is found, what > do we do? Would we have to push out a new version just to now update the > requires line and forcing an update for all users? Which commit do we > use to push out that update (given there will have been changes since > the last release and we may not be ready to push them out in a new > version yet). I don't see how a bug that is only encountered on 25 is different from any other bug in this case. We aren't going to continue to support 25 by continuing to maintain a 9.5.x branch when we go on to 9.6, but as long as we don't e.g. start using e.g. functions that are not present in 25 that cause immediate runtime failures or byte compile failures, then hard blocking users on 25 from installing from elpa at all seems like artificially depriving users of the ability to choose at their own risk (albeit to make the maintainer's lives easier). > An alternative approach is to deliberately make it harder to upgrade org > if your running an unsupported version of Emacs. This would prevent > automatic updates to a version which is not supported and (possibly) doe > sot work, either partially or fully. Manage user expectations by making > it very explicit to the end user they are running a older version of > emacs which may not be compatible with latest version of org.They can > either decide to continue with the existing version they have installed > or they can upgrade to a more recent Emacs or they can install org > manually if they really want to accept the risk and run in an > unsupported configuration. 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 would say something along the lines of "this version of org {org-version} will run on {emacs-version}" but it is not supported. If you still want to install it, please run (setq org-i-know-what-i-am-doing t) and then install the package again" or something like that. Best! Tom
Re: [PATCH] Delete some Emacs 24 compat code
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 versions. Should we put > users through the pain of having to fight the metadata saying that they > can't run org on an old version of emacs when only a tiny subfeature > may or may not be broken? For example, I can load the current > version of org and go through most of my normal workflows without > issue on 25. > > Package-Requires does not mean what it says, what it actually means > is "actively does not work on any versions not specified" which is not > true if we were to say >=26 and would make users' of older versions > of emacs lives harder. What this means is that we could say >=25 > (which is what org.el current has by listing 25.1) because it is possible > to load current versions of org-mode on 25 but not on 24 (which works > only at 9.4.6 at 652430128896e690dc6ef2a83891a1209094b3da). 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. Problem I see with your approach is there will be an expectation that if it lists Emacs 25.x that it works under that version and anything which doesn't work is a bug. People will not check this list, README or NEWS files to verify what version of Emacs is compatible with - if they can use package.el to install it, they will expect that it works without any issues and any encountered are either a configuration error or a bug. Even worse, once a problem with (for example) Emacs 25.x is found, what do we do? Would we have to push out a new version just to now update the requires line and forcing an update for all users? Which commit do we use to push out that update (given there will have been changes since the last release and we may not be ready to push them out in a new version yet). An alternative approach is to deliberately make it harder to upgrade org if your running an unsupported version of Emacs. This would prevent automatic updates to a version which is not supported and (possibly) doe sot work, either partially or fully. Manage user expectations by making it very explicit to the end user they are running a older version of emacs which may not be compatible with latest version of org.They can either decide to continue with the existing version they have installed or they can upgrade to a more recent Emacs or they can install org manually if they really want to accept the risk and run in an unsupported configuration.
Re: [PATCH] Delete some Emacs 24 compat code
> 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 through the pain of having to fight the metadata saying that they can't run org on an old version of emacs when only a tiny subfeature may or may not be broken? For example, I can load the current version of org and go through most of my normal workflows without issue on 25. Package-Requires does not mean what it says, what it actually means is "actively does not work on any versions not specified" which is not true if we were to say >=26 and would make users' of older versions of emacs lives harder. What this means is that we could say >=25 (which is what org.el current has by listing 25.1) because it is possible to load current versions of org-mode on 25 but not on 24 (which works only at 9.4.6 at 652430128896e690dc6ef2a83891a1209094b3da).
Re: [PATCH] Delete some Emacs 24 compat code
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.1 and Emacs Emacs 26.1. > > Please, keep ";; Package-Requires: " version in org.el consistent with such > statement > (Should it be updated for the bugfix branch as well?). > > Such commit may be accompanied by an announce sent to the mail list. Samuel > may check this > declaration in his update script. > The above is good to do and your right, it is hard not to forget to do this. However, this is somewhat independent of whether there has been a commit which breaks compatibility with a version. This is something which should be updated when a new major version of Emacs is released. It really just states which version org is (should be) compatible with. It says little about which versions it actually is compatible with i.e. it might say Emacs versions 28.x, 27.x and 26.x, but that doesn't mean it isn't compatible with 25.x - it only says that if it doesn't work with 25.x, that is not considered a bug. . > The problem is that it is too easy to forget to make such change before > committing of > something that really breaks compatibility. That is a problem, but the real problem is that you don't know you have broken compatibility because your likely no longer testing against that version. Sometimes you will and we should inform the community when we know, but we cannot guarantee we will always let the list know immediately when compatibility is lost for these no longer supported versions.
Re: [PATCH] Delete some Emacs 24 compat code
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 ";; Package-Requires: " version in org.el consistent with such statement (Should it be updated for the bugfix branch as well?). Such commit may be accompanied by an announce sent to the mail list. Samuel may check this declaration in his update script. The problem is that it is too easy to forget to make such change before committing of something that really breaks compatibility.
Re: [PATCH] Delete some Emacs 24 compat code
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 when compatibility is lost. Yes, fully agreed. If my previous message was unclear: it is *good* to inform the list of any compatibility issue (with any Emacsen), but we cannot promise we will warn the list for every breakage as we don't test Org with Emacs <=25. > If you are running an unsupported > versions, either you should avoid updates or be prepared for breakage > without warning. When we do know a commit has broken compatibility, that > information will be relayed to the list, but we cannot guarantee we can > provide such information at the time the change is committed. Running an > unsupported versions is at your own risk. Yes, thanks for articulating this very clearly. -- Bastien
Re: [PATCH] Delete some Emacs 24 compat code
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 concrete terms, based on your example below, we don't know exactly when org loses compatibility with Emacs 25.x because we are no longer testing against that version (we are only testing against 28, 27 and 26). We don't know the precise commit which breaks compatibility with 25 as we are no longer testing against that version, so cannot notify the list when compatibility is lost. Obviously, when we do know, we can notify the list. Sometimes, it is clear that a patch or commit will break compatibility with an old version. However, we cannot provide any guarantee we will always notify the list when that compatibility is lost. Often, this only becomes known when someone posts to the list to say it no longer works. 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 lost. If you are running an unsupported versions, either you should avoid updates or be prepared for breakage without warning. When we do know a commit has broken compatibility, that information will be relayed to the list, but we cannot guarantee we can provide such information at the time the change is committed. Running an unsupported versions is at your own risk. Bastien writes: > 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 test suite against these > versions in order to check that bugfixes and/or new features don't > introduce incompatible code. > > We don't need to run tests against Emacs <=25: if Org runs okay on > Emacs <=25, it's good. If not, users can report it: maintainers are > not bound to fix such incompatibilities and we don't need to know or > to announce them beforehand since we don't make a promise that Org > will run with Emacs <=25. > > On https://orgmode.org/worg/org-maintenance.html I added this: > > It does not mean that Org will not be usable, at least partially, > with older Emacsen: but maintainers are not bound to fix bugs > reported on them. > > WDYT?
Re: [PATCH] Delete some Emacs 24 compat code
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 test suite against these versions in order to check that bugfixes and/or new features don't introduce incompatible code. We don't need to run tests against Emacs <=25: if Org runs okay on Emacs <=25, it's good. If not, users can report it: maintainers are not bound to fix such incompatibilities and we don't need to know or to announce them beforehand since we don't make a promise that Org will run with Emacs <=25. On https://orgmode.org/worg/org-maintenance.html I added this: It does not mean that Org will not be usable, at least partially, with older Emacsen: but maintainers are not bound to fix bugs reported on them. WDYT? -- Bastien
Re: [PATCH] Delete some Emacs 24 compat code
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 release. > > For example, the current release of Org (9.5.4) is compatible with > Emacs 25.1, as Ihor noted. This is older than Emacs 26. If for some > reason Org 9.6 only supports Emacs >=26, let's announce it on the list > and add an entry in etc/ORG-NEWS and orgmode.org/Changes.html. > > I think doing this manually is fine. > > Bug fixes from the maint branch should never change the compatibility > status of Org. Could you please elaborate on how exactly we can determine if a commit changes the compatibility status? We can indeed catch some cases by running tests on older Emacs versions, but it is by no means a reliable measure. Also, I just tried to run make EMACS=emacs-25 test, and it fails on bugfix. Yet, Org can be usable on Emacs 25, but not fully. Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
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, documentation improvement type of activity recently and it is greatly appreciated. it's a kind of user-openness attitude that i think improves the software. by analogy, kind of like including science-oriented research subjects to get knowledge and noticing and priorities instead of imposing an arbitrary wall. On 7/17/22, Bastien Guerry wrote: > 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 https://orgmode.org/worg/org-maintenance.html#emacs-compatibility > > 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 release. > > For example, the current release of Org (9.5.4) is compatible with > Emacs 25.1, as Ihor noted. This is older than Emacs 26. If for some > reason Org 9.6 only supports Emacs >=26, let's announce it on the list > and add an entry in etc/ORG-NEWS and orgmode.org/Changes.html. > > I think doing this manually is fine. > > Bug fixes from the maint branch should never change the compatibility > status of Org. > > Evolutions on the master branch can change the compatibility, but not > break the global promise of being compatible with the last three major > releases of Emacs. > > -- > Bastien > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: [PATCH] Delete some Emacs 24 compat 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 https://orgmode.org/worg/org-maintenance.html#emacs-compatibility 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 release. For example, the current release of Org (9.5.4) is compatible with Emacs 25.1, as Ihor noted. This is older than Emacs 26. If for some reason Org 9.6 only supports Emacs >=26, let's announce it on the list and add an entry in etc/ORG-NEWS and orgmode.org/Changes.html. I think doing this manually is fine. Bug fixes from the maint branch should never change the compatibility status of Org. Evolutions on the master branch can change the compatibility, but not break the global promise of being compatible with the last three major releases of Emacs. -- Bastien
Re: [PATCH] Delete some Emacs 24 compat code
Stefan Kangas writes: > Thanks, please find attached an updated patch. Applied onto main via 0ed0dea22. Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
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 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 would not occur in just a plain git update for such a >> thing but would get a release that gets noted in email and get that >> advance notice], >> >> then upon seeig such email i can stop pulling from git until i am able >> to upgrade emacs. [lots of stuff takes lots and lots of time for me >> in my case] idk if practical, but just saying what seems like it >> would be useful to me. >> >> i would then stay at something reasonably close to the first release >> that does not support that version fo emacs. >> > While what your asking for may sound reasonable, I don't think it is > practical. There is no sudden decision to stop supporting a version in > the sense that suddenly, at that point, the version is no longer > supported. We really only know that a past version is no longer > supported when it stops working and is more than 2 releases behind the > current Emacs version (any less and it is a bug which will get fixed). > > The supported version policy has already been communicated on this > list. That policy will not change without notice, so you know exactly > what is supported at all times. > > There is no precise point where we can send out a message saying a > version is no longer supported. Best that can be done is say that any > Emacs version older than two releases behind the current stable release > is no longer supported. That doesn't mean it won't work, it just means > if there are problems, they won't be fixed and there should be no > expectation it will work if your running an unsupported Emacs version. > > Thing is, no testing is done against older versions, so it isn't always > clear precisely when org stops working with an older unsupported > version. > > Current stable version is 28. Therefore, if your running Emacs 25 or > earlier, you *should not* pull updates from git as they may not be > compatible with your Emacs version. When Emacs 29 is released, stop > pulling from git if your running Emacs <= version 26. > > Of course, none of this is a big issue as you do build from git. Should > you find your most recent pull is no longer compatible with the version > of Emacs your running, it is trivial to revert to the version you were > running before - you just need to do a checkout for the earlier > revision and rebuild. As pointed out elsewhere in this thread, > package.el has minimum version spec, so this isn't an issue for > package.el users. > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: [PATCH] Delete some Emacs 24 compat code
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 [note: i presume > and hope this would not occur in just a plain git update for such a > thing but would get a release that gets noted in email and get that > advance notice], > > then upon seeig such email i can stop pulling from git until i am able > to upgrade emacs. [lots of stuff takes lots and lots of time for me > in my case] idk if practical, but just saying what seems like it > would be useful to me. > > i would then stay at something reasonably close to the first release > that does not support that version fo emacs. > While what your asking for may sound reasonable, I don't think it is practical. There is no sudden decision to stop supporting a version in the sense that suddenly, at that point, the version is no longer supported. We really only know that a past version is no longer supported when it stops working and is more than 2 releases behind the current Emacs version (any less and it is a bug which will get fixed). The supported version policy has already been communicated on this list. That policy will not change without notice, so you know exactly what is supported at all times. There is no precise point where we can send out a message saying a version is no longer supported. Best that can be done is say that any Emacs version older than two releases behind the current stable release is no longer supported. That doesn't mean it won't work, it just means if there are problems, they won't be fixed and there should be no expectation it will work if your running an unsupported Emacs version. Thing is, no testing is done against older versions, so it isn't always clear precisely when org stops working with an older unsupported version. Current stable version is 28. Therefore, if your running Emacs 25 or earlier, you *should not* pull updates from git as they may not be compatible with your Emacs version. When Emacs 29 is released, stop pulling from git if your running Emacs <= version 26. Of course, none of this is a big issue as you do build from git. Should you find your most recent pull is no longer compatible with the version of Emacs your running, it is trivial to revert to the version you were running before - you just need to do a checkout for the earlier revision and rebuild. As pointed out elsewhere in this thread, package.el has minimum version spec, so this isn't an issue for package.el users.
Re: [PATCH] Delete some Emacs 24 compat code
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 would not occur in just a plain git update for such a thing but would get a release that gets noted in email and get that advance notice], then upon seeig such email i can stop pulling from git until i am able to upgrade emacs. [lots of stuff takes lots and lots of time for me in my case] idk if practical, but just saying what seems like it would be useful to me. i would then stay at something reasonably close to the first release that does not support that version fo emacs. On 6/30/22, Ihor Radchenko wrote: > 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 emacs version number] so that i can prepare at my glacial >> luddite pace. this is probably already done, but making it prominent >> beforehand might help signal the need for changes with lots of time or >> simplify git stuff [e.g. pull soon as the last pull and make a note >> not to pull after that, which prevents the need for figuring out >> rebasing again]. > > org.el contains the following: > ;; Package-Requires: ((emacs "25.1")) > > So, if you install Org from ELPA using built-in Emacs package manager, > Org will fail to install on older Emacs versions (AFAIU). I am not sure > if package.el if going to fall back to earlier Org version though. > > In addition, we might also announce the oldest supported Emacs version > in https://orgmode.org/Changes.html. Either manually, or as a part of > some automated release script. Bastien, WDYT? > > Best, > Ihor > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: [PATCH] Delete some Emacs 24 compat code
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 emacs version number] so that i can prepare at my glacial > luddite pace. this is probably already done, but making it prominent > beforehand might help signal the need for changes with lots of time or > simplify git stuff [e.g. pull soon as the last pull and make a note > not to pull after that, which prevents the need for figuring out > rebasing again]. org.el contains the following: ;; Package-Requires: ((emacs "25.1")) So, if you install Org from ELPA using built-in Emacs package manager, Org will fail to install on older Emacs versions (AFAIU). I am not sure if package.el if going to fall back to earlier Org version though. In addition, we might also announce the oldest supported Emacs version in https://orgmode.org/Changes.html. Either manually, or as a part of some automated release script. Bastien, WDYT? Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
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 prepare at my glacial luddite pace. this is probably already done, but making it prominent beforehand might help signal the need for changes with lots of time or simplify git stuff [e.g. pull soon as the last pull and make a note not to pull after that, which prevents the need for figuring out rebasing again]. On 6/30/22, Ihor Radchenko wrote: > 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 older Emacs versions should >> be supported, but I remember the following message: >> >> Bastien. Re: Supported Emacs version. Mon, 22 Nov 2021 07:39:22 +0100 >> https://list.orgmode.org/87fsrolmn9@gnu.org/ > > This is a valid point in general. However, Org mode already fails when > you try to load it using Emacs 24 (correct me if I am wrong). So, Org > cannot be used with Emacs 24 de-facto. Yet, nobody complained and I do > not see much point keeping partial compatibility. > > There is a reason to keep old compatibility code only when Org works in > general and only some new optional libraries cannot be used. This is not > the case for Emacs 24, AFAIK. > > Best, > Ihor > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: [PATCH] Delete some Emacs 24 compat code
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 older Emacs versions should > be supported, but I remember the following message: > > Bastien. Re: Supported Emacs version. Mon, 22 Nov 2021 07:39:22 +0100 > https://list.orgmode.org/87fsrolmn9@gnu.org/ This is a valid point in general. However, Org mode already fails when you try to load it using Emacs 24 (correct me if I am wrong). So, Org cannot be used with Emacs 24 de-facto. Yet, nobody complained and I do not see much point keeping partial compatibility. There is a reason to keep old compatibility code only when Org works in general and only some new optional libraries cannot be used. This is not the case for Emacs 24, AFAIK. Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
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 supported, but I remember the following message: Bastien. Re: Supported Emacs version. Mon, 22 Nov 2021 07:39:22 +0100 https://list.orgmode.org/87fsrolmn9@gnu.org/ Org is made of many areas and partial backward-compatibility can still be useful. When people report compatibility problems with Emacs <26, we can guide them so that they enhance org-compat.el. It is not because we don't promise compatibility for Emacs < 26 that we should prevent backward-compatibility for Emacs < 26, and the all-or-nothing approach would actually prevent it.
Re: [PATCH] Delete some Emacs 24 compat code
Ihor Radchenko writes: > We usually put obsolete aliases into org-compat.el instead of sprinkling > them across the various .el files. Please move the > define-obsolete-function-alias statements to org-compat. Thanks, please find attached an updated patch. 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-map) (org-font-lock-ensure): Delete compat aliases. Update callers. (org-define-error): Redefine as obsolete function alias for `define-error'. Update callers. (string-suffix-p): Delete compatibility definition. * lisp/org-fold-core.el (org-fold-core--seq-partition): Delete private function and update callers to use `seq-partition'. * lisp/org-macs.el (org-without-partial-completion): Move from here... * lisp/org-compat.el (org-without-partial-completion): ...to here. Redefine as obsolete function alias for `progn'. --- lisp/org-clock.el | 2 +- lisp/org-compat.el| 38 ++ lisp/org-fold-core.el | 22 ++ lisp/org-goto.el | 2 +- lisp/org-macs.el | 13 - lisp/org-src.el | 2 +- lisp/org-table.el | 6 +++--- lisp/org.el | 4 ++-- lisp/ox-html.el | 2 +- lisp/ox-odt.el| 2 +- lisp/ox-org.el| 2 +- lisp/ox.el| 2 +- 12 files changed, 16 insertions(+), 81 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 7d99e5087..e0b2d3ce6 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -2122,7 +2122,7 @@ fontified, and then returned." (org-mode) (org-create-dblock props) (org-update-dblock) -(org-font-lock-ensure) +(font-lock-ensure) (forward-line 2) (buffer-substring (point) (progn (re-search-forward "^[ \t]*#\\+END" nil t) diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 10c125a2c..d8104e7e7 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -904,12 +904,6 @@ context. See the individual commands for more information." ((and (eq window-system 'w32) (fboundp 'w32-get-clipboard-data)) (w32-get-clipboard-data -;; `set-transient-map' is only in Emacs >= 24.4 -(defalias 'org-set-transient-map - (if (fboundp 'set-transient-map) - 'set-transient-map -'set-temporary-overlay-map)) - ;;; Region compatibility @@ -961,13 +955,6 @@ Pass COLUMN and FORCE to `move-to-column'." string) (apply 'kill-new string args)) -;; `font-lock-ensure' is only available from 24.4.50 on -(defalias 'org-font-lock-ensure - (if (fboundp 'font-lock-ensure) - #'font-lock-ensure -(lambda ( _beg _end) - (with-no-warnings (font-lock-fontify-buffer) - ;; `file-local-name' was added in Emacs 26.1. (defalias 'org-babel-local-file-name (if (fboundp 'file-local-name) @@ -994,29 +981,8 @@ Pass COLUMN and FORCE to `move-to-column'." (defun org-release () "N/A") (defun org-git-version () "N/A !!check installation!!")) - - -;;; Functions for Emacs < 24.4 compatibility - -(defun org-define-error (name message) - "Define NAME as a new error signal. -MESSAGE is a string that will be output to the echo area if such -an error is signaled without being caught by a `condition-case'. -Implements `define-error' for older emacsen." - (if (fboundp 'define-error) (define-error name message) -(put name 'error-conditions - (copy-sequence (cons name (get 'error 'error-conditions)) - -(unless (fboundp 'string-suffix-p) - ;; From Emacs subr.el. - (defun string-suffix-p (suffix string ignore-case) -"Return non-nil if SUFFIX is a suffix of STRING. -If IGNORE-CASE is non-nil, the comparison is done without paying -attention to case differences." -(let ((start-pos (- (length string) (length suffix - (and (>= start-pos 0) - (eq t (compare-strings suffix nil nil - string start-pos nil ignore-case)) +(define-obsolete-function-alias 'org-define-error #'define-error "9.6") +(define-obsolete-function-alias 'org-without-partial-completion 'progn "9.6") ;;; Integration with and fixes for other packages diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el index 88072852d..68a777de9 100644 --- a/lisp/org-fold-core.el +++ b/lisp/org-fold-core.el @@ -1304,25 +1304,7 @@ property, unfold the region if the :fragile function returns non-nil." ;; Move to next fold. (setq pos (org-fold-core-next-folding-state-change spec pos local-to -;;; Hanlding killing/yanking of folded text - -;; Backward compatibility
Re: [PATCH] Delete some Emacs 24 compat code
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--seq-partition >> #'seq-partition "9.6") Also, thinking a bit more. Do we need to obsolete the private function? I think it is safe to remove it completely. Best, Ihor
Re: [PATCH] Delete some Emacs 24 compat code
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 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--seq-partition > #'seq-partition "9.6") > diff --git a/lisp/org-macs.el b/lisp/org-macs.el > index da68d8b8f..07c177b0b 100644 > --- a/lisp/org-macs.el > +++ b/lisp/org-macs.el > @@ -70,18 +70,7 @@ > ... > +(define-obsolete-function-alias 'org-without-partial-completion 'progn "9.6") ^#'progn We usually put obsolete aliases into org-compat.el instead of sprinkling them across the various .el files. Please move the define-obsolete-function-alias statements to org-compat. Best, Ihor
[PATCH] Delete some Emacs 24 compat code
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 From 6e854576494f918c36cdd0ce698793574af494df 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-map) (org-font-lock-ensure): Delete compat aliases. Update callers. (org-define-error): Redefine as obsolete function alias for `define-error'. Update callers. (string-suffix-p): Delete compatibility definition. * lisp/org-fold-core.el (org-fold-core--seq-partition): Redefine as obsolete function alias for `seq-partition'. Update callers. * lisp/org-macs.el (org-without-partial-completion): Redefine as obsolete function alias for `progn'. --- lisp/org-clock.el | 2 +- lisp/org-compat.el| 37 + lisp/org-fold-core.el | 24 lisp/org-goto.el | 2 +- lisp/org-macs.el | 13 + lisp/org-src.el | 2 +- lisp/org-table.el | 6 +++--- lisp/org.el | 4 ++-- lisp/ox-html.el | 2 +- lisp/ox-odt.el| 2 +- lisp/ox-org.el| 2 +- lisp/ox.el| 2 +- 12 files changed, 18 insertions(+), 80 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 7d99e5087..e0b2d3ce6 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -2122,7 +2122,7 @@ fontified, and then returned." (org-mode) (org-create-dblock props) (org-update-dblock) -(org-font-lock-ensure) +(font-lock-ensure) (forward-line 2) (buffer-substring (point) (progn (re-search-forward "^[ \t]*#\\+END" nil t) diff --git a/lisp/org-compat.el b/lisp/org-compat.el index baad39459..85f66587a 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -904,12 +904,6 @@ context. See the individual commands for more information." ((and (eq window-system 'w32) (fboundp 'w32-get-clipboard-data)) (w32-get-clipboard-data -;; `set-transient-map' is only in Emacs >= 24.4 -(defalias 'org-set-transient-map - (if (fboundp 'set-transient-map) - 'set-transient-map -'set-temporary-overlay-map)) - ;;; Region compatibility @@ -961,13 +955,6 @@ Pass COLUMN and FORCE to `move-to-column'." string) (apply 'kill-new string args)) -;; `font-lock-ensure' is only available from 24.4.50 on -(defalias 'org-font-lock-ensure - (if (fboundp 'font-lock-ensure) - #'font-lock-ensure -(lambda ( _beg _end) - (with-no-warnings (font-lock-fontify-buffer) - ;; `file-local-name' was added in Emacs 26.1. (defalias 'org-babel-local-file-name (if (fboundp 'file-local-name) @@ -994,29 +981,7 @@ Pass COLUMN and FORCE to `move-to-column'." (defun org-release () "N/A") (defun org-git-version () "N/A !!check installation!!")) - - -;;; Functions for Emacs < 24.4 compatibility - -(defun org-define-error (name message) - "Define NAME as a new error signal. -MESSAGE is a string that will be output to the echo area if such -an error is signaled without being caught by a `condition-case'. -Implements `define-error' for older emacsen." - (if (fboundp 'define-error) (define-error name message) -(put name 'error-conditions - (copy-sequence (cons name (get 'error 'error-conditions)) - -(unless (fboundp 'string-suffix-p) - ;; From Emacs subr.el. - (defun string-suffix-p (suffix string ignore-case) -"Return non-nil if SUFFIX is a suffix of STRING. -If IGNORE-CASE is non-nil, the comparison is done without paying -attention to case differences." -(let ((start-pos (- (length string) (length suffix - (and (>= start-pos 0) - (eq t (compare-strings suffix nil nil - string start-pos nil ignore-case)) +(define-obsolete-function-alias 'org-define-error #'define-error "9.6") ;;; 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 @@ -1304,25 +1304,9 @@ property, unfold the region if the :fragile function returns non-nil." ;; Move to next fold. (setq pos (org-fold-core-next-folding-state-change spec pos local-to -;;; Hanlding killing/yanking of folded text - -;; Backward compatibility with Emacs 24. -(defun org-fold-core--seq-partition (list n) - "Return list of elements of LIST grouped into sub-sequences of length N. -The last list may contain less than N elements. If N is a -negative integer or 0, nil is returned." - (if (fboundp 'seq-