-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could you please make the tag regularly after every update? #2696
Comments
If you want the tags to identify "the versions that are recommended to be used", then you just need to use |
@levlam The answer was very strange and unprofessional and had nothing to do with my request! |
If you add me to the project, I will be honored to register and update the tags for you at the right time and even get a GitHub release to notify all those who started the project and make it more beautiful. |
It is explained in the links that there is no "right time" for tags. Tag is just an alias for commit with some special meaning. If you need nothing special from the tag, then you can also use HEAD commit from the master branch always. |
@levlam git push origin --delete v1.8.0
git push origin --delete v1.7.0
... |
No, the tags are made on purpose. But as you should not use Telegram 2.5 (and you can't even download old app versions from any official distribution source), you should not use any old TDLib version and use the latest public version instead. If you want to run some Github action, then you need to run it on every public TDLib commit. |
I'm create tag and release in this repository: https://github.com/njfamirm/td |
you can use it, Also I'm interested to do this in current repo |
These words are completely true and I am successful with you, but believe me, regular release has its uses and is very beautiful and practical. |
@njfamirm it's nice, thank you very much. |
Any new commit makes everyone aware of the changes made to the project.
You provided no use cases for tags. |
@levlam The use case for tags is that some Linux distributions (like Void Linux) will only package software that has associated release tags so that there is a direct download link for the tarball containing the source files (they don't use Git to clone repositories). By not adding release tags for your patch releases in the 1.8 series, users of apps that leverage tdlib on Void Linux will never have the most up to date version of the library. This is blocking my use of telega.el specifically because it expects a version of tdlib greater than 1.8.20, but I'm sure it will cause problems for many others. Since it's not costly from a time or effort perspective to create a tag for each version bump and there are some out there who do need it, could you please reconsider? |
Each app version requires specific TDLib version and is incompatible with all other TDLib versions. See #1718 (comment) for more details.
Specific version of telega.el requires specific version of TDLib to be able to use its API. It is theoretically possible to support multiple TDLib versions by an app such as telega.el, but this would require enormous additional amount of work by the author of telega.el. Therefore, currently the distribution must provide dozens TDLib packages simultaneously, one for each TDLib version, from which only a few will be used by other packages. Is it an option for Void Linux package manager? Instead, apps usually bundle TDLib as it is done in https://zevlg.github.io/telega.el/#running-telega-server-in-docker. Providing shared libraries as packages improves many things, for example, allows sharing of the same library between different apps, improving memory usage and performance, allows fast adoption of security patches by distro maintainers for libraries with stable API. Unfortunately, none of this can be applied to TDLib. If you want an opinion on the matter from a person you know, I can point you to https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/. |
I see, thanks for taking the time to explain this. I'm not sure if packaging multiple versions within a minor version range would be acceptable to Void (I'm not a maintainer, just a user) but my guess is that they'd prefer not to do it. I'll use an alternate approach to getting tdlib working for telega.el. Thanks for linking the Docker image support, I was not aware of that! |
What I want to mention is that an end user is unlikely to use multiple telegram clients in one computer at one same time.
If we have git tag, we may then build and install using https://docs.brew.sh/Versions to install the version we need like brew install [email protected] Or make our own tap to build the latest version to keep align with the client's supported version. |
Why to waste so much your and contributors time for a one second job? The tags are easier to read and compare. Additionally with semantic versioning they allows to understand criticality of change. We always know that it should be safe to upgrade to the latest patch version. For example, in the TG plugin for a Pidgin now used a commit hash instead of a tag and this makes it harder to understand. The GitHub provides a nice feature to see list of commits from the last release or compare between tags. I wanted to see it but I couldn't. |
|
@stokito All TDLib versions are binary compatible when used with JSON interface, but you can never just replace TDLib with a different version without adjusting source code of the app using it. TDLib has 1-3 feature releases monthly and it is never safe to update it without examining changes in https://github.com/tdlib/td/blob/master/td/generate/scheme/td_api.tl. See all my comments above for explanation, why tags are useless with TDLib for most their usual use cases.
On Github, as in git, you can easily compare any 2 commits. For example, see https://github.com/tdlib/td/compare/072cba1..8d08b34e. |
Telegram provides a lot of nice tools and I am grateful for both the platform and the APIs/tools. I understand that this is a lot to maintain and appreciate the effort. I can understand how yet another request which seems not so important can be annoying. If there is a strong reason not to add tags to the GitHub repo, maybe another compromise would be to have a way to add version numbers to the automated build instructions (which are really nice, by the way). If that was OK, I'm confident that I or one of the other people on this thread would be happy to add a PR to support that. Since telega.el requires a specific version of tdlib, I did the following as a manual work around: I searched for I would still prefer to have tags for each release version, but if that is not feasible I think the above would be helpful for other users that need to build with a different version. Thanks. |
I made a Docker image of this project and update it regularly, but I don't notify about new updates!
I can't build regularly in my CI/CD and unfortunately we are still using version v1.8.0!
Every once in a while, I checked this project and saw that there was still no new version (from the last tag) and I thought that this project was abandoned by Telegram and will not continue anymore! Until today I randomly saw 21 new updates since the last tag that I didn't see and I was shocked!
https://github.com/Alwatr/containers/tree/next/tdlib
Could you please make the tag regularly after every update?
The text was updated successfully, but these errors were encountered: