Le 06/06/2016 22:47, Richard Heck a écrit :
On 06/06/2016 04:27 PM, Guillaume Munch wrote:
Le 06/06/2016 20:33, Georg Baum a écrit :
Jean-Marc Lasgouttes wrote:
Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
Yet, most of the file format changes are very simple. I wonder
whether one could introduce a single compilation variable to
disable them, and ask developers to enclose file-format-specific
code between the corresponding #ifdefs. (For instance in my last
file format change all that was needed to be enclosed was the
parsing code.) This would allow the release of "master versions
without file format changes", either as nightlies or as official
"x.5" versions as Pavel suggested by Pavel in another message
(without having to maintain three branches in parallel).
This looks too complicated to me. And eventually there will be
changes that cannot be treated like that, and all the previous
work on small changes will be useless.
The current workflow of testing master all at once before a release
has proven to be too complicated. Notice that only the input and output
of the features has to be treated with #ifdefs, not the whole changed
code. Do you have a particular example situation in mind which would be
too difficult?
The problem, as I'll elaborate below, is that the new features can't be
pulled
apart from the changed input and output (when that changes).
As far as I know the biggest file format change for 2.2 was Enrico's
work on separators. On the looks of it, preserving the previous format
with a switch was entirely doable (see c668ebf6).
I don't see how this would be possible. The new code introduces a separator
inset. There is no longer any separator style. I can imagine writing the
old layout
to a file and then having the document open properly in 2.1.x, but then
it will not
have opened properly in 2.2.x (i.e., master).
Yes, one would need to use the old layouts and therefore keep them in a
backup dir.
The problem is even more serious with new types of inset, say. I have been
thinking about adding a proper endnote inset (to deal with some XHTML
issues).
Is the proposal just not to write it to the file? Or to disable the
feature entirely?
Yes, with disabling the input, I also meant disabling the ways to
introduce them in the interface. New Lfuns can be disabled with an early
return, and changed ones keep the old code in the #else branch.
Then it does not get tested.
The point of the proposal is to enabling the early testing and release
of *non-file-format* changes. Then for a proper master release only
file-format changes remain to be fully tested.
