Deprecating the first function, a compatibility strategy

NOTE: This post refers to an old version of instadeq that is no longer available.

It happened, a user reported that a function was behaving weird, she did date ( current date ) to record and the month value in the resulting record was wrong, it was 10 instead of 11.

As a programmer I noticed instantly, in the date _ to record implementation I forgot the fact that in Javascript Date.getMonth returns zero indexed months, that means January is 0 and December is 11.

I wanted to fix the error, but there are many users out there that may be using this function, how could I fix it without breaking existing visualizations?

My first quick idea was one I used in the past for other kind of migrations, when reading the visualization configuration next time, check if there's a call to the "old" version, if so, change it for a call to the "new" and fixed one.

There's a problem with that solution, if the user noticed the problem and used the month field somewhere else in the logic, the change will break that logic by having months from 2 to 13.

Building a program transformation that would detect and fix that is really hard, and I may introduce weird changes that will surprise users.

That's why I decided to introduce a new version of the function alongside the current one, they both have the same representation in the UI, from now on only the new one can be selected, but the old one will still be available for existing logic that uses it.

The only difference is that when displaying the old version, a warning sign will appear, on hover it will explain that this version had a problem and that you should select the new version and change any month + 1 logic you may have.

Here's an example with the old and new function one after the other, notice the month field in a and b on the left side.

On mouse hover:

This was done in a generic way to deprecate other functions in the future the same way.

We will try hard to avoid having to use it.