updateNewMessage format is out of spec

[hnatt]

I'm using tdlib-ruby bindings library, and it expects that a Message object contains sender attribute, as specified in the API docs: https://core.telegram.org/tdlib/docs/classtd_1_1td__api_1_1message.html (does 1_1 means it's way out of date? if so, why it's linked on the official page?)

But with some recent updates the message became like this:

  [ 3][t29][1638900662.693040847][Td.cpp:4227][#10][!Td][&td_requests]    Sending update: updateNewMessage {
    message = message {
      id = 134217728
>>    sender_id = messageSenderUser {
        user_id = 123456
      }
      chat_id = 123456
      sending_state = null
      scheduling_state = null
      [...]
    }
  }

tdlib-ruby cannot process such update and neither would anyone without prior knowledge of the schema changes. Previously the sender_id was called sender. I would keep using the version of tdlib that worked for me, but with the rolling release it's hard to find it. I assumed it's safe to always use the latest master to build tdlib as it would maintain backwards compatibility, but apparently not.

I don't mean to appear entitled to a service that I don't pay for, but I would appreciate a little guidance on how to keep my integration stable with release tags now gone, and such breaking changes introduced in the rolling release. Should I stick to a certain commit, or is there any better way? Sounds counter-intuitive and begs the question of why you would get rid of release tags. When upgrading, how do I keep awareness of breaking changes?

[levlam]

On-site TDLib documentation is for the latest tagged version 1.7.0, The latest TDLib API scheme and documentation can be found at https://github.com/tdlib/td/blob/master/td/generate/scheme/td_api.tl.

When upgrading, how do I keep awareness of breaking changes?

API is changed frequently. You can use git diff/git log for https://github.com/tdlib/td/blob/master/td/generate/scheme/td_api.tl to find all the changes since the previous version.

If your wrapper have autogenerated classes for binding, they need to be regenerated.

[hnatt]

@levlam thanks for the quick response! I would love to keep using the tagged version 1.7.0, but it's of no use because of UPDATE_APP_TO_LOGIN (#1758). You mentioned in that thread that master is more stable than 1.7.0, and I misunderstood that (totally my fault, you've probably meant stable as in less crashes, not as in not breaking changes to the API) and jumped to building from master, which frustratingly enough, worked for some time until the change to Message class came along.

Sorry for the rant, I guess my question is: how do you build a particular version number, say 1.7.9? Is it in the commit with "Update version to 1.7.9." in the message? If so, why not tag the commit to make it easier to manage updates for the binding libraries?

[levlam]

You've probably meant stable as in less crashes, not as in not breaking changes to the API

Yes, I meant exactly this. The API itself is unstable and changes with each minor version.

How do you build a particular version number, say 1.7.9? Is it in the commit with "Update version to 1.7.9." in the message?

No, this is the commit on the day of the corresponding Telegram release. The version is increased, because TDLib source code is pushed to Github and there are major API changes when compared to the previously available master version. The recommended to use TDLib 1.7.9 was released the same day, the next TDLib version 1.7.10 is pushed to Github. You can find the corresponding commit by a huge jump in the past in commit dates. For 1.7.9 it is 9f6b369.