You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a continuation of the discussion begun with pull request #406 .
On 5/31/21 4:27 PM, Christophe Dervieux wrote:
As the template is on CTAN, I am no longer supposed to include the
cls file in rticles, correct?
Yes exactly.
The new template has a number of options that were simply absent from
the previous template, so if I update to the new template I will
probably have to break backward compatibility in some way. Is there a
preferred way to do this, for example, keeping the old oup_article style
and making a oup_author_template_article style?
This is a good question. I think we need to take the decision based on the real differences between the template. Absent options in previous template could have defaults is not provided for example. If there is no other way than having breaking change, we'll need to thing of the best way to do so. Having a new function is not really the way. I would thing an argument in the function (like version or else) that would allow to switch between old and new template - it would select the right file for example.
I haven't played with it enough to know if adapting to the new format will break things or if workarounds can be found, but the template is quite different. For example, it requests that you split addresses into their many parts, which was not the case before. I will have to see if these are merely suggestions that can be ignored or not. My goal would be to not break things if it can be avoided, but this may be inevitable.
However, the aim of rticles package is to be able to write articles to publish in Journals so I would not mind breaking old Rmd documents if to publish to OUP you need to us the new templates only. Users who want to re-render an old report created with articles could install the version of rticles that works for them. Am I wrong to think that ?
You are probably not "wrong", but I must admit it drives me crazy how quickly R code ages. If we could at least let a paper from 2020 be compiled in 2021, that seems like a good thing...
Anyway, if we could avoid in hard change and breakage, it is best to do so.
The text was updated successfully, but these errors were encountered:
If we could at least let a paper from 2020 be compiled in 2021, that seems like a good thing...
Oh yeah for sure. I don't think it will be no more possible to build - the question will be what should be the default behavior.
I mean the new template could live with the old template. Then something trigger the use of one or the other.
So either the default is the old one, and previous will render without any change but new one could be use when opt-in (probably an argument in the format function)
Or the new one is the default, and if someone wants to re render a previous article, it would require to opt-in to the new format (unless it can be detected - old Rmd source = old format).
Just saying that we won't break completely. There will always be ways to opt-in previous template if require.
And we could have a deprecation period to have a smooth transition.
I think we'll know more once you look into the differences.
This is a continuation of the discussion begun with pull request #406 .
On 5/31/21 4:27 PM, Christophe Dervieux wrote:
I haven't played with it enough to know if adapting to the new format will break things or if workarounds can be found, but the template is quite different. For example, it requests that you split addresses into their many parts, which was not the case before. I will have to see if these are merely suggestions that can be ignored or not. My goal would be to not break things if it can be avoided, but this may be inevitable.
You are probably not "wrong", but I must admit it drives me crazy how quickly R code ages. If we could at least let a paper from 2020 be compiled in 2021, that seems like a good thing...
The text was updated successfully, but these errors were encountered: