[GH-ISSUE #193] [discussion] Features for Termdash 1.0.0 #112

New issue

Open

opened 2026-03-03 16:22:29 +03:00 by kerem · 1 comment

kerem commented

2026-03-03 16:22:29 +03:00

Owner

Originally created by @mum4k on GitHub (Apr 28, 2019).
Original GitHub issue: https://github.com/mum4k/termdash/issues/193

It is probably a good time to start discussing what other features we want to deliver before we release version 1.0.0. For background 1.0.0 has a special meaning in Semantic Versioning, it comes with a promise of API stability all the way until 2.0.0.

Therefore we should prioritize features that might come with breaking API changes as we shouldn't be doing those after 1.0.0. Secondly we should prioritize features without which Termdash is hard to use or the use cases are significantly limited.

Any ideas welcome here, please feel free to throw them in this thread.

Tracking so far:

We should finish documentation in the wiki.

Originally created by @mum4k on GitHub (Apr 28, 2019). Original GitHub issue: https://github.com/mum4k/termdash/issues/193 It is probably a good time to start discussing what other features we want to deliver before we release version 1.0.0. For background 1.0.0 has a special meaning in [Semantic Versioning](https://semver.org/spec/v2.0.0.html), it comes with a promise of API stability all the way until 2.0.0. Therefore we should prioritize features that might come with breaking API changes as we shouldn't be doing those after 1.0.0. Secondly we should prioritize features without which Termdash is hard to use or the use cases are significantly limited. Any ideas welcome here, please feel free to throw them in this thread. Tracking so far: - [ ] We should finish documentation in the [wiki](https://github.com/mum4k/termdash/wiki).

kerem added the

question

label

2026-03-03 16:22:29 +03:00

kerem commented

2026-03-03 16:22:30 +03:00

Author

Owner

@ferdinandyb commented on GitHub (Aug 29, 2025):

Just stumbled on this project, looks cool! One thing that came to my mind is that it has graphics, and tcell is rather limited in that regards (no sixel or kitty). Switching to e.g. vaxis should open up the possibility for "proper" graphs (I think vaxis in particular is not hard to use instead of tcell).

@ferdinandyb commented on GitHub (Aug 29, 2025): Just stumbled on this project, looks cool! One thing that came to my mind is that it has graphics, and tcell is rather limited in that regards (no sixel or kitty). Switching to e.g. vaxis should open up the possibility for "proper" graphs (I think vaxis in particular is not hard to use instead of tcell).

kerem referenced this issue

2026-03-03 16:23:23 +03:00

[PR #151] [MERGED] Refactoring the codebase to clearly mark internal libraries. #222