Dear Scott, thank you for the fast answer. Sorry to bother you again.
On 2017-10-27, Scott Kostyshak wrote: > On Fri, Oct 27, 2017 at 07:38:32AM +0000, Guenter Milde wrote: ... >> > Indeed, our "Development" manual covers this: >> > While the conversion routine is required to produce a document that >> > is equivalent to the old version, the requirements of the reversion >> > are not that strict. If possible, try to produce a proper reversion, >> > using ERT if needed, but for some features this might be too >> > complicated. In this case, the minimum requirement of the reversion >> > routine is that it produces a valid document which can be read by an >> > older LyX. If absolutely needed, even data loss is allowed for the >> > reversion. >> > The current code (without the patch) clearly already satisfies the >> > "minimum requirement". >> The current conversion routine does *not* produce a document that is >> equivalent to the old version: > The minimum requirement, as quoted above, is that a valid document is > producecd that can be read by an older LyX. I interpret this to mean > just that a .lyx file is produced that can be opened in older LyX > without parser errors. In any case, equivalence is not the minimum > requirement. This is the minimum requirement for *reversion* (i.e. backward conversion). For (forward) *conversion*, the requirement is "to produce a document that is equivalent to the old version". The current code satisfies the minimal requirement for reversion but it fails the requirement for conversion: some old documents are not equivalent to the old version after converting to 2.3! ... >> I can propose a medium and a minimal patch: >> The minimal patch just removes the ZWSP hack, >> the medium patch also sets the new setting based on content. > Thanks for your new proposal. If the new proposal gets support after > rc1, I am fine to consider it, and as I said I could spend some time > helping with the testing. > If other LyX developers are in favor, we can even wait a couple of days > to fix this before rc1. I will not push the tag yet (I will tag and tar > locally and send the resulting tars to our packagers). So if we decide > as a group that there is an important fix we need in rc1, then I can > retar and send new tars to the packagers and they can make new binaries. > For now, I'm planning to go forward with rc1 unless others speak up, > since the only other opinions that I interpret are that Enrico does not > think any patch is worth addressing this issue at this point, and that > Richard also looked and did not propose delaying rc1. I see. Thank you for the explanations and offer to test. Would it help to put the remaining issues in a new bug report (closing the all to verbose current one)? Thanks again, Günter G
