On 2016-03-30, Guenter Milde wrote:
> On 2016-03-30, Richard Heck wrote:
>> On 03/30/2016 11:26 AM, Guenter Milde wrote:

Dear Lyxers,

...


>>> I propose a patch which I ask you to review also under the
>>> perspective that this may become an example for further handling of
>>> such cases (see the "guide on updating layouts" thread).

...

>>> * Add a new layout that supports the new *.cls version in a clean way.

>>>   In this case, the new layout imports the old one. Alternatively, the
>>>   old layout could be based on the new one.

>> My only suggeestion (I don't use this class so can't comment
>> intelligently on the implementation) would be to do it the other way
>> around. The reason is just that it seems that would make maintenance
>> easier. Presumably, changes we might need to make would really be for
>> the new version of the class. It would also make it easier to release
>> yet another version of this one, if that were necessary.

> However, it is more work, morec changes, more ways to break something But
> yes, at least when the next incompatible version comes out, it should be
> old importing new.

Thinking about it while writing aastex6.layout, there is a major
disadvantage of the "old loads new" approach:

* aastex6.layout inputs aastex.layout and currently only changes the name
  and referenced LaTeX class file.
  
  I future, it should also support commands new in aastex v. 6.
  
  Adding new styles to aastex6.layout is simple and does not require any
  changes to the old aastex.layout.
  
  OTOH, if the old aastex.layout would input the new aastex6.layout, any
  adding of a new style there would require a new "NoStyle" in the old
  layout.
  
  
Generally, as the old layout is stable but the new a "moving target", the
method "new loads old" is preferable, as this allows to keep "old" at the
proven status. (This is als important, because we usually do not test with
obsolete LaTeX classes/packages.)

Günter
  
  

Reply via email to