fdo69552 backward compatibility with optional arguments in calc functions

[Eike Rathke]

Hi Winfried,

On Friday, 2013-11-29 07:55:44 +0100, Winfried Donkers wrote:

> >> What is the best way to proceed?
> >What follows is just a brainstorm, there may be quirks..
> That looks like a long way to go (and IMHO we should include WEEKNUM/ISOWEEKNUM too, then).

Yes, of course, and FLOOR and maybe others that suffer from similar
incompatibilities.

> I am beginning to think (call it a brain wavelet, anyway far from a brain storm, I'm carefull with my sparse brain matter)  there may be another option.
> With new versions, new functions are introduced, which cannot be read by older versions. We accept that.
> In this case, it's the same function, but with a new option (i.e. not having to provide argument significance).
> Is it really a problem that -if and only if the optional argument is ommitted- older versions cannot read it?

The problem is you don't know if it would be a problem ;-)
In mixed environments where people are collaborating using different
releases it matters. They can be well educated and precautious and avoid
such traps, but could also never have seen the help text or
FunctionWizard and/or just use the function like it naturally should be,
without superfluous extra parameters.

> With a proper mention in the help text (possibly in the function wizard hint as well), users of the ODF-compliant version are warned that if they want backward compatibilty, they need to provide the optional argument.

People don't read help texts unless they encounter a problem, even then
only sometimes but that doesn't matter here ;-)  The author/generator
side would not have the problem, it would be the consumer side using the
earlier release.

> For export to Excel format, the same applies and (soon) there is a choice of several Excel-CEILING/FLOOR functions.

Which btw reminds me that at some point we could introduce mappings to
defined ODFF functions for some of those when saving as ODF instead of
COM.MICROSOFT.* in case the document is to be read by consumers that do
not implement the MS ones. Just as a side note.

> In short, I tend to be a supporter of a change at once with proper information of it to the user as opposed to your gradual (5 versions) change with risks of complications should anything happen with respect to the developer feeding the patches to these 5 versions or the function definitions themselves.

Actually the risk is quite low, as every release would introduce
a self-maintained state. To shorten things the final cut could be done
at every step if the sequence turned out to be unmaintainable.

Fortunately we do have some time now for 4.3 to think things over. I'm
not clinging to my proposal but I think it's best for the users
who exchange documents.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20131129/b29e3f82/attachment.pgp>