Skip to content
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

Regarding update ETA and features in newest Telegram Desktop versions #420

Open
EricKotato opened this issue Jan 17, 2023 · 4 comments
Open

Comments

@EricKotato
Copy link
Member

EricKotato commented Jan 17, 2023

When update?

Short answer

soon (thanks dotvhs)

Long answer

There is no ETA. I work on Kotatogram in my spare time. No time means no progress. No energy also means no progress. If it happens for a long time, then there is no update for a long time.

Updating original source code is hard. There are big features in Kotatogram (like local folders) and even small features may require many places to patch. The hardest thing is that there's no stable internal API in TDesktop. Updates may break a lot of features, which can require a lot of time to fix. Sometimes features are rewritten to adapt to new code. Of course, all of this requires time and energy. Without them everything stops.

It doesn't mean Kotatogram is dead. I still intend to update it. But that doesn't mean that I have time and energy to do it in nearest future. No ETA is still no ETA. And since there is no ETA, the answer would be the same: soon.

When release is near, there is usually a lot of activity happen on GitHub (namely dev branch). There are merge commits, post-merge fixes, etc.

I want to see some progress!

You can read about it in Telegram channel: https://t.me/kotatogram_dev

What if I want to test it?

Test versions are published in https://t.me/KotatogramTestVersions. Keep in mind that they will have a lot of bugs.

Why my issue is closed?

If you're asked "when", then answer is in the first section.

If you've requested a feature that is implemented in newer Telegram Desktop versions, then making a separate issue for it makes no sense since this feature will naturally appear in newer Kotatogram versions once TDesktop source code will be updated.

If you're asking about "This message is not supported ... please update" messages, and you're on latest version, then it means that update which supports following messages is not out yet. If at this point you want to ask "when", then read the first section.

You may think that these issues will help the project in any way. In fact, they do the opposite: they create the noise. And without time and/or energy, the noise causes nothing more than stress.

There is no need for "reminder" issues. I remember it just fine, since I still use Kotatogram on daily basis.

Closing these issues also keeps more important issues (like bug reports or feature requests) more visible. Otherwise this repo will be drown in "when update" issues.

I can't use this outdated app anymore! I'm leaving to search another!

I won't stop you here. You can even install multiple apps at the same time, if you want.

If you're in search of more up-to-date unofficial app, you might be interested in 64Gram or Forkgram.

You can even use your old tdata folder, but be aware that downgrading of profile is not supported. If you'll use the profile of app with newer TDesktop version with app with older TDesktop version, then the profile will be recreated, which will lead to losing your sessions. In case of uncertainty, backup your tdata folder before doing anything risky.

Can I help?

As I said earlier, updating source code is hard. The trick is not to just add new code on top of existing one. Updating source code is about making old features work as they should even after update.

If you still want to try yourself in this hard task, you can try to fork and clone this repo and try it yourself. You'll also need to fork lib_ui and cmake_helpers repos.

Note: you don't need to clone lib_ui and cmake_helpers separately. Just clone kotatogram-desktop repo with --recursive parameter and add your forks as remotes in submodules.

Also do not forget to add original repos as remotes (https://github.com/telegramdesktop/tdesktop, https://github.com/desktop-app/cmake_helpers and https://github.com/desktop-app/lib_ui).

Usually the updating process happens like this:

  1. Fetch original repo commits
  2. Merge dev branch of original repo with dev branch of Kotatogram repo
  3. Resolve the conflicts if there are any (the hardest part)
  4. Add some post-merge fixes
  5. Package and release the update

When changes are subtle, it's easy to update source code. However, most of the time this is not the case. In fact, with Kotatogram growing in features this becomes more and more harder.

That's why I made patches-track branch.

patches-track is a support branch which rebases Kotatogram changes on top of TDesktop's instead of using chronological order. This branch consists of two main parts:

  1. Original TDesktop commits;
  2. Kotatogram commits which are split by feature.

Splitting by feature allows to pinpoint what feature is broken while rebasing retains update progress.

However, chronological order is important because it tracks small changes (like PRs or fixes) which can be easily reverted if needed and preserve original author link. That's why even with patches-track the dev branch is still a default one. When patches-track will be rebased on top of latest TDesktop code, it will be merged with dev.

Here's an advice if you want to try it:
Rebase on top of commit from branch, not on top of the branch. You might be tempted to do a rebase in one shot. This may work with subtle changes but not when there are many breaking changes. Which commit to pick is depends on how breaking the changes are. Sometimes you can easliy add 20 commits in one rebase and sometimes it will be hard to add even 1 commit. But if you've successfully added at least one commit then it's a progress, which is much better then trying to do too much without any visible progress.

Of course, it will take time. But if you will do it faster than me, you can send it as PR to me. But in this case you should publish your patches-track too, because it will make future source code updates easier.

Note that patches-track will be periodically updated with force push to retain update progress. You may want try to start from patches-track-old branch which is roughly the same, but rebased onto 3.5.2 (like latest 1.4.9 beta). This branch will be updated only after update is released.

There are currently also two flavors of patches-track: patches-track-4.8.4 and patches-track-4.14. They will be also temporarily preserved until new stable or beta version.


Use the comments of this issue for anything update-related like "when" questions, even if you know the answer. Or to report spelling error in this issue. Or to ask a question about how to use that mysterious patches-track branch. Or to pray. Etc.

@EricKotato EricKotato pinned this issue Jan 17, 2023
@dotvhs
Copy link

dotvhs commented Jan 17, 2023

Or to pray

I don't have to pray, I have full faith in Kotato and in The Creator. Long live Kotatogod.

And thank you for all your hard work!

@wodim
Copy link

wodim commented Jan 17, 2023

image

Copy link
Contributor

github-actions bot commented Jul 9, 2024

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

@github-actions github-actions bot added the stale label Jul 9, 2024
@EricKotato
Copy link
Member Author

bot
no
stop it
bad bot

@EricKotato EricKotato removed the stale label Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants