Uwe Stöhr wrote: > > The same holds for moderncv. The author does support backward > > compatibility so I would be interested to see what actually does not work > > anymore. > > I had a look today and I cannot fiddle it out. The underlying table > structure until modernCV 1.0 makes it complicated. With almost every > release I found bugs and reported them to the modernCV maintainer. But > during last summer I lost track and cannot tell which version needs what. > As my spare time is very limited I cannot work further on this. > But let's live with this limitations. Since modernCV 1.x the things are much > easier and I think for the future backward compatibility will be much > easier.
I had a look for you and checked the changes (http://www.lyx.org/trac/changeset/58f6767e2c/lyxgit#file1) (1) You added 14 styles of "InPreamble" type (CVStyle, CVColor, FirstName, FamilyName, Title, Address, Mobile, Phone, Fax, Email, Homepage, ExtraInfo, Photo and Quote). None of these are needed to keep the layout working with recent releases of moderncv, since all these statements can still be given via the preamble, as it is the case in current LyX releases. On the contrary, I think such a huge number of new layouts require a file format change, and lyx2lyx should write those layouts into the preamble on reversion (2) You added 5 required arguments to the style "entry". This is a file format change in itself, since these argument _must_ be reverted to ERT. The change itself is also not urgently needed. We can still use the ERT braces workaround, as done before. Same for DoubleItem. (3) The \cvitem command now has a required instead of an optional argument. I cannot find a corresponding change in the modernsv changelog, so I suppose the syntax was always like this, and this is just an attempt to reduce ERT. => Not strictly needed for branch (4) New styles: ItemWithComment, DoubleListItem, MakeCVtitle, MakeLetterTitle, MakeLetterClosing, Recipient, Date, Opening, Closing, Enclosing These are indeed new commands as of moderncv 1.0, but these are new features, and not providing them will not break moderncv support. The remaining changes are cosmetic. In sum: As much as these changes enhance the support for moderncv, none of them is really needed to keep moderncv working. Since the changes are so multitude, this is clearly not something we would like to do just within a maintenance release cycle. On the contrary, with regard to the massive changes I would really argue in this case that we need either a new layout or -- even better -- add proper conversion/reversion routines, as I've done for beamer. > If you disagree feel free to modify the layout as you think it should be. No, this is your responsibility. Jürgen
