[mythtv] Comments requested on two bugs

[Peter Bennett]

On 3/26/23 17:30, Gary Buhrmaster wrote:
> On Sun, Mar 26, 2023 at 6:48 PM Peter Bennett <pb.mythtv at gmail.com> wrote:
>>
>> On 3/26/23 13:18, David Engel wrote:
>>> On Sun, Mar 26, 2023 at 11:19:20AM -0400, Peter Bennett wrote:
>>>> There are two bugs I have logged, with my recommended fixes.
>>>>
>>>> https://github.com/MythTV/mythtv/issues/739
>>>>
>>>> I am proposing removing the use of std::move. The different ways of
>>>> accessing QString, and how the memory is managed com into this. I ran some
>>>> tests of the solution, and I could not find any memory leaks. If there is
>>>> anything wrong with this approach please let me know.
>>> I don't know enough about this issue to comment.
>>>
>>>> https://github.com/MythTV/mythtv/issues/740
>>>>
>>>> In one field the API is returning different values in xml and json. The fix
>>>> may affect users of the xml API. I believe we need to fix it anyway.
>>> Returning the same value in both modes is desirable.  However, is this
>>> API element new in pre-v34?  Or IOW, do we know how many existing, API
>>> users that would break?
>> This element has been there since 0.28 and I believe it has been
>> behaving this way since then.
>>
>> I don't know how many users there are of the api.
>>
>> If I change the api to return names in all cases and change the method
>> that translates the code to a description so that it accepts names as
>> well as codes, that should be the least impact.
> I have said this before, but API versioning, returning
> two different names (the old unchanged, and the newer),
> or an entirely new API endpoint is the proper way
> forward when you want to change what an API
> returns/performs and not impact existing users (and
> deprecate the old on master, and delete on
> master + 2(ish)).  Otherwise you just need to say
> the quiet part out loud, which is the API has no
> stability (and one should feel free to just poke
> things into the database, as it is just as unstable
> as the API that the project offers).
> _______________________________________________

Thank you Gary for the response.

I looked at the documentation at 
https://www.mythtv.org/wiki/DVR_Service#GetUpcomingList . It shows in 
the example there that the Status is numeric:

<Status>-3</Status>

If I run the API now I get the text description in status in the xml 
format but the numeric value in the json format. That is clearly a bug. 
Today the wsdl shows it it a string. It seems that somewhere along the 
line it was changed from an int to a string but the json version still 
has a number and the documentation was not updated.

So your rule was violated at some point.

A question is, what about bug fixes? Do we keep the buggy version around 
because some people are using it that way?

Another factor is that the version on port 6544 will never be fixed, but 
the version on port 6744 will. Does this count as a new end point? It is 
planned that eventually the code on port 6744 will become the only 
server and its port will change to 6544.

Peter