Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>>> We can check for that in Org Lint and warn the user.
>>
>> That would be a really good idea!
>
> Done.

Great - thanks.

>
>> Before deleting it, one should get a warning that a certain feature is
>> deprecated. At the moment, it is only mentioned in the help (as far as
>> I am aware).
>
> It has been mentioned in the manual for the last two years. See footnote
> in (info "(org)Header arguments in Org mode properties").

Yes - that's true. But who of the longer org users reads the manual of
features they use regularly?

org-lint seems to become the place where these changes can be marked and
the user be notified - that is really brilliant.

I could imagine the following automatic workflow to enable automatic
linting of org files upon opening when they were saved under an older
(or unknown) version of org:

1) a new argument is introduced :

  #+FILE_ORG_VERSION: 8.3beta

2) when opening an org file, this version is checked. The following
cases are possible:

  - parameter not present: assume that file version is older and run org-lint
  - file version older then org version: run org-lint
  - file version identical to org version: just open
  - file version newer: run org-lint

3) after reviewing the results, org-lint could offer to update the file
version (#+FILE_ORG_VERSION) to the version of org-mode. This should be, by
the way, possible to do even when running org-lint manually.

4) this behavior should be possible to disabled by an additional header
  #+ORG_FILE_VERSION_CHECK: f
  but not via  emacs.el as this should be the standard behavior.

One could go even one step further, to define a minimum and maximum org version so
that one get's a warning that the file requires a different org version
than used:

#+REQUIRED_ORG_VERSION: min:8.0

would require org newer and including than 8.0

#+REQUIRED_ORG_VERSION: max:8.0

would require org older and including than 8.0

#+REQUIRED_ORG_VERSION: min:8.0 max:8.9.9 

a version between and including 8.0 and 8.9.9 because e.g. a feature used
was only present during these releases or

#+REQUIRED_ORG_VERSION: min:8.0 max:8.0 

require version exactly version 8.0

where the warning comes when the version is different to the ones
specified.


I really think that org files should have the org-versions that was used
to write them and the org version required to run them.

Even though that org-documents are documents, I kind of see them as
*add-ons* to org, because they can contain code to be execute,
variables to be set, and added functionality to the standard org. So to
make this more robust, to store the org version used to create the file
version and the required org versions would make perfect sense to me.

This should obviously only include release, alpha, beta, rc and not git
checkout values.

Cheers,

Rainer

>
> Regards,

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982