On 2019-01-17, Kornel Benko wrote:
> Am Mittwoch, 16. Januar 2019 14:20:37 CET schrieb Scott Kostyshak 
> <skost...@lyx.org>:

>> We should at some point
>> come up with a guideline. For example, we could test validity of .lyx
>> files and convergence for the previous 4 version file formats, and test
>> (in addition to validity and convergence) compilation of only the
>> previous 2. Or something like that. I don't have any strong opinion on
>> this. I guess we have to think about what is the best way to catch
>> important regressions.

> +1

I'd like to look at this from a user perspective:

* The most serious bugs are, when my old documents no longer work.

* It is even more severe, 

  - if I cannot open them in LyX
  - or if they become corrupted in a hidden way -- subtle changes that are
    easily overlooked but may be fatal (missing content due to missing
    characters or paragraphs, say).

* Failure to export to an earlier LyX version is less severe, especially
  for really old versions. If everything else fails, I may try via LaTeX.
  
This is reflected in the unconditional commitment to ensure old files work
while back-conversion is only provided "if reasonable".

However, currently our lyx2lyx export tests do it the other way round:

* starting point are files from the newest or last stable version

* we always test a round circle, so there is no chance to test 
  regressions to forward-conversion in a file that fails with back-conversion.
  
* we only test if a file opens in LyX, not if LyX can generate output.


Suggestions:

1. test with documents originally from old LyX versions.

   We do have a large sample in lib/(doc|examples|templates) in the
   respective version branches in the repository.

   test old documents for

   a) opening in lyx
   
   b) export to the default output
   
2. test with recent documents

   a) export to old LyX formats   
   
   b) re-opening the exported file
   
   c) convergence
   
   d) export to the default format
   
While this increases the number of tests, it allows easier localisation of
errors and also a more fine-grained tagging (inverting only non-fixable
parts of the round-circle). 

However, the most important thing is that the most urgent regressions
(problems with existing old documents) can be identified and be given 
preference status when assigning valuable developer time.

Thanks,
Günter

Reply via email to