Why are there no new versions anymore ?

[freebrowser1]

Version 118 is now over a year old, while until that version, every 2-3 months a new version was released.
But in the source code repository I can see that there are more recent changes.

So why is there no new release ?

[sylirre]

Because all work for app now is done by one person: @agnostic-apollo. Some changes incomplete, some not pushed.

Termux doesn't hire anyone to work on repositories, people work on it when want to do so and have time.

Be patient or use latest git version. To have frequent updates, the application part needs skilled maintainers. For now only package part has enough of them.

Btw, the readme document already states this:

@termux is looking for Termux Application maintainers for implementing new features, fixing bugs and reviewing pull requests since the current one (@fornwall) is inactive.

[l1t1]

you can get new build from https://github.com/termux/termux-app/actions/workflows/debug_build.yml

[glibg10b]

For anyone having issues installing these builds, try uninstalling all Termux plugins first (e.g. Termux:API, Termux:Boot and Termux:Widget)

[luisdavim]

@agnostic-apollo if the current versions in master for termux-app and termux-api are stable can't they be released to F-droid?

Thanks.

[sp4rkie]

why don't you not just install the github builds? These are more recent than anything else in the world :-) If that is important to you...

[luisdavim]

It's not about that. If it's not stable don't release it. I'm not trying to rush anything. But keeping changes local doesn't help anyone. Making them available helps other contributors, specially when these local changes are mentioned in several pull requests, saying that the changes in the pull request will have to wait for some unpublished changes....

[sylirre]

Drastic changes to the code often needs to be restructured, like split on commits and so. Many changes could be experimental or not finished, the final implementation can be significantly different or be removed at all in the final variant.

Lots of commit->revert->rebase->force-push cycles won't help contributors as they may need to do unnecessary work by adapting their code for each pushed changes. Better to wait final changes at the master branch and then adjust pull request.

[agnostic-apollo]

But keeping changes local doesn't help anyone.

In addition to what @sylirre said, I am not keeping changes local for the lulz. If I could have pushed the changes, I would have. However, many, if not most changes are interdependent due to rewrite/refactor of core parts of termux. I can either push all of them together or nothing, since currently committed code will likely not build and even if it did, things may be broken due to other changes that are not committed yet. Fixups to my own changes is also being continuously done too while issues present themselves, and master branch of github is not a testing ground. Yes, pull requests not being merged is an issue and I am really sorry for that but I am not doing that deliberately, but because a major rewrite/refactor phase of any big project would cause such problems due to major conflicts, and since I am the only one working on 5-6 app refactors, things can only move at my own pace. It has taken months to do these things because I am not just adding features, but I am writing libraries and frameworks for making adding features easily possible that is asked by users in multiple repos, which takes time. And its not one app I am writing the changes for, like it usually happens, but most changes I make need to consider how it will affect all the termux plugin apps, current and future termux forks, current and future package managers, different targetSdkVersions and android versions, plans for providing termux app as a library, and all the apps that may use termux-shared library for their own personal use or to use it to interact with temux app or any of its forks using termux apis, which may exist in primary user or secondary users/profiles, while having to keep backward compatibility and "hardcoded paths" termux design, not really an easy or quick task when you actually do it, specially alone. Moreover, the "no-pull-request-merge" phase would occur again when termux-shared and app modules are split into multiple libraries in future and it won't be avoidable, which would again also take significant time.

I have however committed most of the stuff now and not much is left on the to-do list before I push changes.

[luisdavim]

I was not suggesting you should push them to master, only to make them visible in a public branch.

And I do appreciate your work.

[RaWolFoX]

@sylirre fornwall recently done some changes in his repo. so he is active?. Why he not active in termux development?. Im just curious 😁

[sylirre]

Yes, that is known that his account is active on GitHub. We also had few answers from him in one of our issues after long time of silence. But so far there is no interest shown in further participation in Termux development.

In age of 40+ people usually have more important tasks to do than play with terminal app on their Android device or spending hours on bumping package versions.

[agnostic-apollo]

Age is still not an excuse to not transfer or give access to infrastructure accounts to active devs. There is obviously no obligation for him to be active in termux development or support, but there would be or should be for giving others access at least.

[Sanzium]

I know this is marked as closed and the lack of developers is sad and complicated.
But I would like to suggest for you to push the GitHub Actions builds to the Releases page, marking them as pre-release. I read somewhere this can be done automatically through the GitHub Actions workflow, so as soon as it is built, it is pushed to the Releases, marked as "pre-release" so people just looking for the latest stable version won't get these builds.
My suggestion is to make it easier for the ones who want to use/test the bleeding edge builds to keep the app up-to-date (I personally use Obtainium for this). I've been using these builds for a long time, termux-app and termux-styling, and they have been pretty stable. And I think it's nice to have beta-testers to try to contribute to the project.
Finally, I would like to thank you devs for making such a great software for free.

[RaWolFoX]

Im also using action builds of these apps👍🏻

[sylirre]

Automatic publishing by GitHub Actions is done already. However per-commit builds won't be published. They are not releases of any kind, even not pre-releases.

The current master branch doesn't represent real development state of Termux application. Many changes not pushed, so the latest commit is not really bleeding edge version. Wait v0.119 release and then test it.

[Sanzium]

I see, I am sorry, it was my misunderstanding about the state of the master branch in Termux's development. Thanks for clarifying.

[ShalokShalom]

I think this is a bit of a chicken and an egg situation. Personally, I would refrain from investing a lot of time into a project, that cant do a regular release within a long time.

Particulary, when the project has not only hundreds of commits in the master branch, but even a couple of larger branches besides this, who are not merged yet.

I personally value my own time, and this is simply not a good, sustainable release mechanism, and it will distract further contributors.

Just looking at the "last updated" field in F-Droid, lets me think the app is probably dead, and I will not even download it as an user, not to say anything about contributing.

Release early, release often, is a well established common practice for good reason.

It allows for a much better feedback cycle, better reception from the community, and a more dynamic development overall.

But each their own. 🙂

[agnostic-apollo]

Particulary, when the project has not only hundreds of commits in the master branch, but even a couple of larger branches besides this, who are not merged yet.

You may want to read #3213 (reply in thread)

Changes is master are not ready and not final to be released as a stable version. A pre-release is planned for coming weeks (hopefully).

Personally, I would refrain from investing a lot of time into a project, that cant do a regular release within a long time.

Just looking at the "last updated" field in F-Droid, lets me think the app is probably dead, and I will not even download it as an user, not to say anything about contributing.

Lot of big projects release stable updates after years of work, it obviously does not mean project is somehow dead. Check debian for example (similar goal to us), their stable updates happen every two years. Obviously, they are a much bigger project, but release time point still stands. If someone is thinking such projects are dead, they need to think again and check activities on repos and community channels instead. Moreover, last 10 releases happened within a few months, this is a major refactor of all the core parts, hence is taking this long, next major update will also take a lot of time due to refactoring required for termux-core library and TAPM package manager. Termux packages are also continuously being updated. Give me more people who are skilled and can work up to the required standards, who are willing to work full time (5-6 days a week) with me, for free (beer), and I may be able to expedite some things, but not everything can be with all the blockers across multiple repos/orgs. I am having to work on way too many things alone to do things faster.

• https://www.debian.org/News/2021/20210814
• https://en.wikipedia.org/wiki/Debian_version_history

Release early, release often, is a well established common practice for good reason.

No, releasing before things have been made final and standardized is a bad way to do stable releases, since if you are continuously breaking stuff, its bad for both users and maintainers. Maintainers are also the ones who would have to deal with all the issues reported by users when their things break, not the users who are in their update-fast craze. Not to mention this update-fast craze in today's world is a major reason for all the bugs and security issues (that everyone then complains about), writing safe, good and stable (non-breaking) code takes time.

[ShalokShalom]

I do think Debian does a horrible release policy, for the exact reasons I quoted. They waste massive amounts of ressources. I am sure you got bug fixes for the existing architecture, and those could have been part of 119. There is no need, to publish unfinished work. And I appreciate your work.

[TomJo2000]

I do think Debian does a horrible release policy, for the exact reasons I quoted. They waste massive amounts of ressources. I am sure you got bug fixes for the existing architecture, and those could have been part of 119. There is no need, to publish unfinished work. And I appreciate your work.

You are not entitled to updates.
Termux is a volunteer project, the main app is currently maintained by a single developer.
If you do not like the pace of development, do something about it.

Termux 0.118 is a close to feature complete terminal emulator.
Packages are updated separately from the main application,
by no means are we "wasting massive amounts of resources".
We simply do not have the same capacity or need for development on the main application as there is for the supporting tooling, packages, etc.

[glibg10b]

I don't think @ShalokShalom is expressing any form of entitlement.

[luisdavim]

Any updates on this? Would it be possible to have a branch with the rewrite made available?