After upgrade to 1.7.0 updates come with delay 60s. its critical for me

[rocket-builder]

After upgrade to 1.7.0 updates come with delay ~6-60s. its critical for me. Before on version 1.6.0 updates usually come immediately. What i can do with this? What could be the problem?

[levlam]

Update to the latest TDLib version from master. If this wouldn't help, send TDLib's log with verbosity level 4 to @tdlib_bot in Telegram.

[rocket-builder]

I already use latest TDLib 1.7.0

[levlam]

The latest master commit now is 7ac3c2b with TDLib 1.7.6.

[rocket-builder]

The latest master commit now is 7ac3c2b with TDLib 1.7.6.

how can I find out the current version of TDlib? I didn't find the version in github.

[levlam]

The current recommended version is the latest version from master branch.

[rocket-builder]

The current recommended version is the latest version from master branch.

I mean how i can check version number

[levlam]

The first update sent from TDLib is updateOption with the option "version".

[rocket-builder]

The first update sent from TDLib is updateOption with the option "version".

I mean how to check last TDLib version from this repo master, because in tags last version is 1.7.0

[levlam]

How would you use the tags for the check?

[keleftheriou]

I believe what @rocket-builder is trying to ask is “what is the last released version”, ie “the most recent stable version” we should be using.

In #1627 @levlam indicated that "basically, each time a version is stable enough and can be marked with a tag, there is a newer version with the latest features, which should be used instead.”

That advice is almost contradicting and does not balance the trade-offs between stability and recency at all, because there’s a reasonable chance that “newer version with the latest features, which should be used instead” has stability issues that haven’t been identified yet. Additionally, the given advice is said to only apply “Most of the time”, which feels like a way of saying “most of the time, just not when something is really broken in a recent commit” - which developers currently have no way of knowing.

Instead, there should always be a release pointing to the commit of the library that is recent enough to include most major features, but also old enough to have confidence (from actual usage) that there are no major issues with it.

The scenario that such a structure helps prevent is one where a developer pulls the latest library commit, pushes out a release of their own app, and later finds out that one of the most recent library commits introduced a significant issue that shouldn’t have made it to production.

I also think asking developers to be manually hunting down the appropriate commit themselves or asking here every time is inadequate, error-prone, and duplicative. It would be much better for developers, users, and Telegram, to have a tagged release of the library. This would be Telegram saying: “this is the commit you should be using right now, we’ve tested it enough and it includes that version’s bug fixes & improvements”. Or, in other words: “this is the last known good commit”. Sometimes this might be a very recent commit, other times it might be days, weeks, or months behind the head - it all depends on how Telegram decides to balance stability vs new features, and that balance naturally changes over time.

The only way “Update to the latest TDLib version from master” can be considered reasonably safe is if all commits have been deployed and tested before being pushed onto master, which is not what’s happening as far as I can tell.

[levlam]

@keleftheriou

You are generally right, but I don't see a way to achieve both absolutely stable and feature-rich app in the same time with monthly updates. Instead, Telegram release cycle goes as follow:

• Private alpha implementation.
• Beta testing on thousands (or hundreds thousands for some apps) users. Currently, most TDLib updates are beta-tested via Unigram.
• Source code pushing.
• Fixing issues, not discovered using beta testing, if any.

So whenever a source code is pushed to Github, it is already tested. And only the code considered stable enough is pushed to Github.

because there’s a reasonable chance that ... has stability issues that haven’t been identified yet

The previous history of TDLib updates has shown that such a chance is rather neglible instead of being "reasonable". In rare cases of such issues, they are identified and fixed very fast.

Instead, there should always be a release pointing to the commit of the library that is recent enough to include most major features, but also old enough to have confidence level (from actual usage) that there are no major issues with it.

This is the exact problem. With monthly releases you can't have all recent features and to be absolutely sure that there are no major issues. The confidence increases over time and one week isn't enough to achieve high confidence even wtih millions of users.

The scenario that such a structure helps prevent is one where a developer pulls the latest library commit, pushes out a release of their own app, and later finds out that one of the most recent library commits introduced a significant issue that shouldn’t have made it to production.

In this case the developer pulls fixed TDLib version from master and pushes another release. The developer has alternative approach to wait a week or two before introducing new features to app users, but this way looks worse to me.

This would be Telegram saying: “this is the commit you should be using right now, we’ve tested it enough and it includes that version’s bug fixes & improvements”

After TDLib 2.0 I plan to release minor versions every month just before the next version is released. But this wouldn't be "this is the commit you should be using right now", instead it would be "this is the most stable commit right now". The recommended commit to use would still be the last commit from the master branch.

[levlam]

Tagged TDLib 1.8.0 version has been released.