Put a 1.7.10 tag

[abcdw]

Put a 1.7.10 tag, please. So downstream distributions can package newer version of tdlib.

[isopen]

https://github.com/tdlib/td/releases/tag/v1.7.0
tagged this 28 Nov 2020

[dancojocaru2000]

@isopen That's 1.7.0, a release from one year ago, not 1.7.10.

[isopen]

@levlam It looks like release 1.8.0 is not ready yet?

[levlam]

@isopen Yes, 1.8.0 is in the work.

[abcdw]

@levlam It looks like release 1.8.0 is not ready yet?

And it seems that 1.7.0 doesn't work already. So it would be nice to have some intermediate release, while 1.8.0 still WIP. To make it easier for different distributions to update the package and keep application based on it working. I updated tdlib package for GNU Guix to an almost random commit, which isn't a good practice, but at least people can use their tg clients now. https://issues.guix.gnu.org/52371

[levlam]

To make it easier for different distributions to update the package
and keep application based on it working.

It doesn't work this way. You can't update TDLib in distributions and expect all apps to work. See #1718 (comment) for some more details.

[abcdw]

It is a different and not completely relevant issue, which has its own workarounds and solutions. The problem I referring to is that latest available tag of tdlib is pointing to non-working version. And downstream distributions now can't have ANY working tg clients based on tdlib or provide a development environment with working tdlib.

[levlam]

In fact, 1.7.0 still works. You just can't create a new account there and can log in to 32-bit account only through another logged in app.

[dancojocaru2000]

"Still works. Just can't register or login. But if you manage to get past that, it works."

Don't get me wrong, I get it, it works for people who are already logged in or for one specific login case.

Packaging a new version of tdlib is not only advantageous for already written applications, but for people wishing to write a new application as well.

It's weird that the commit mentions v1.7.10, yet it isn't tagged.

[levlam]

No, you should be able to log in in case app didn't provide an up-to-date version. For example, telega.el has one, so the users can be asked to update. Login via code to another app also was allowed.

About the mentioned commit see #1783 (comment). This is not the commit anyone should use, unless they want to ship the app the same day the official clients were released.

[dancojocaru2000]

The recommended to use TDLib 1.7.9 was released the same day, the next TDLib version 1.7.10 is pushed to Github.

And how would one find such recommended to use TDLib?

Or, for example, how would one build a Telegram client that is able to create a new user account?

[levlam]

And how would one find such recommended to use TDLib?

Recommended to use TDLib version is the latest version from master branch. This is no different from usage of the latest autoupdated Telegram clients.

[Thaodan]

And how would one find such recommended to use TDLib?

Recommended to use TDLib version is the latest version from master branch. This is no different from usage of the latest autoupdated Telegram clients.

Which requires all upstream clients to move as fast.
Not meant as an attack, its already much better since you push the changes to github much faster now.

[abcdw]

On 2021-12-12 09:50, Aliaksei Levin wrote: > And how would one find such recommended to use TDLib? Recommended to use TDLib version is the latest version from master branch. This is no different from usage of the latest autoupdated Telegram clients.

I still not see the reason, why tags are not present, when version is bumped. Just put 1.7.9, 1.7.10, etc, so people can find/reference commit by tag instead of searching changes in source code and looking for commit hash and downstream distributions and package managers can provide newer version of tdlib for development, other tg clients or whatever.

…

-- Best regards, Andrew Tropin

[levlam]

@abcdw See #1627 (comment).

[nmlorg]

I still not see the reason, why tags are not present, when version is bumped. Just put 1.7.9, 1.7.10, etc, so people can find/reference commit by tag instead of searching changes in source code and looking for commit hash and downstream distributions and package managers can provide newer version of tdlib for development, other tg clients or whatever.

As I understand it, TDLib versions don't reflect changes to TDLib, they identify which version of the Telegram server they can talk to. @levlam is essentially saying you should treat every commit as a bump to TDLib's de facto patchlevel ([1.7.9].0.1, [1.7.9].0.2, etc.).

This would imply TDLib never adds new features, nor breaks API compatibility, except when it's simultaneously adding support for a new server. And, more importantly, once TDLib has added support for a new version of the protocol, clients stuck using an older version of the protocol do not get updates for any reason (i.e. once there's a [1.7.10].0.0 or [1.8.0].0.0, there will never be another [1.7.9].0.x, even if there's a catastrophic problem).

[levlam]

Tagged TDLib 1.8.0 version has been released.

[njfamirm]

I'm create tag and release in this repository: https://github.com/njfamirm/td