Maintaining my first project: part II

It has been two months since I wrote Maintaining my first project: part I, and a few things happened, others are planned.

First release

Monday 18th, 2021 was the date of the first release of this copy of Husky, the 1.0.2-beta1. It is a beta because:

  1. I do not have enough experience with the codebase to identify every single thing that could cause a bug, or be a bug.

  2. The old issue tracker has a lot of bugs, some of them reproducible, some of them without any indication whatsoever. This makes the task of fixing stuff more dificult.

    I am fixing what I find and can reproduce right now.

I expect to use the application and find issues that can be fixed, and also, if any new user wants to test the application, I gladly accept bug reports. You have the Husky contributing guide at your disposal.


I do not plan to add a CI/CD to the project. The reason is that I do not generate versions for each single commit, and I am more than comfortable releasing versions to test and report issues.

However, I might add again fastlane support in order to make it easy for those who want to generate their own version using a CI/CD. This will be all documented in the Husky building guide, which will be written any time soon.

Refactoring the application

I intend to, eventually, rewrite the internal architecture of the application following a Clean architecture + MVVM approach in order to improve maintainability of the code. Also, the application will be single-Activity.

My idea is to port everything that Husky is able to do right now, and then, start adding features like moderation tools, for example. This, as you might imagine, will require a lot of testing.

One of the most expected features, which is real-time streaming, will be added too, I am not forgetting about those users!

Mergin from Tusky

The refactor will make almost imposible to merge anything from Tusky, if needed, so changes, bugfixes and features will have to be manually ported. This is a tech debt I am more than comfortable assuming.


The application, right now, has two sets of translations: those from Tusky, and the specific ones for Husky. Since I do not intend to merge more from Tusky, both will be merged in only one set of strings.xml (in all languages).

This will not only make easier to track translations, but also, it will remove the husky folder, which means one less flavor config, which means less time for Gradle to make its thing compiling the app. It is a silly thing, but it will be done in time (because there are a lot of strings).

Sending patches

Patches are welcome if they fix bugs. As stated in the contributing guide, this workflow will be done by email.

Because the application will suffer a huge refactor over time, new features will be added in the future, for now, porting the current ones and fixing bugs are high-priority tasks (in fact, I started the refactor already).

I will make sure that new versions with bugfixes still work while I make the refactor, so I can still release new versions.

Man, this is a lot!

There is a lot of things to be done and a few of them made. I still do not have a roadmap of what I would like to acomplish, for example. The refactor requires a huge plannification, because it will break things and testing is a must-do here.

Still, I am happy to contribute to the community somehow. I have been wanting to do this for a long time and I never steped up to do it, until now.

Oh, and Husky 1.0.2-beta2 has released today!

Any questions or comments? Please use my public inbox by sending a plain-text email to ~captainepoch/ [mailist etiquette].