[GH-ISSUE #788] Build Semantic Versioning Releases

kerem commented

2026-03-04 01:06:11 +03:00

Owner

Originally created by @Klaus-Tockloth on GitHub (Dec 31, 2022).
Original GitHub issue: https://github.com/rivo/tview/issues/788

For better use in production it would be helpful if the tview project builds releases according to Semantic Versioning. Something like "v1.2.3".

Originally created by @Klaus-Tockloth on GitHub (Dec 31, 2022). Original GitHub issue: https://github.com/rivo/tview/issues/788 For better use in production it would be helpful if the tview project builds releases according to Semantic Versioning. Something like "v1.2.3".

kerem closed this issue

2026-03-04 01:06:11 +03:00

kerem commented

2026-03-04 01:06:12 +03:00

Author

Owner

@rivo commented on GitHub (Jan 1, 2023):

This has been discussed at length before. See #442. Also, from the main README:

I try really hard to keep this project backwards compatible. Your software should not break when you upgrade tview.

@rivo commented on GitHub (Jan 1, 2023): This has been discussed at length before. See #442. Also, from the main README: > I try really hard to keep this project backwards compatible. Your software should not break when you upgrade `tview`.

kerem commented

2026-03-04 01:06:12 +03:00

Author

Owner

@Klaus-Tockloth commented on GitHub (Jan 7, 2023):

The advantage of semantic versioning for me is that it has semantic (major.minor.fix).

Semantic Versioning versus your pattern:
v1.2.0 versus v0.0.0-20221128165837-db36428c92d9
v1.2.1 versus v0.0.0-20230104153304-892d1a2eb0da

@Klaus-Tockloth commented on GitHub (Jan 7, 2023): The advantage of semantic versioning for me is that it has semantic (major.minor.fix). Semantic Versioning versus your pattern: v1.2.0 versus v0.0.0-20221128165837-db36428c92d9 v1.2.1 versus v0.0.0-20230104153304-892d1a2eb0da

kerem commented

2026-03-04 01:06:12 +03:00

Author

Owner

@rivo commented on GitHub (Jan 7, 2023):

That's circular reasoning. The question is, why do you need semantic versioning? Describe a situation where you have problems if it's not semantic versioning.

@rivo commented on GitHub (Jan 7, 2023): That's circular reasoning. The question is, why do you need semantic versioning? Describe a situation where you have problems if it's not semantic versioning.

kerem commented

2026-03-04 01:06:12 +03:00

Author

Owner

@mih-kopylov commented on GitHub (Jan 24, 2023):

@rivo I'm also interested in semantic versions.

And here's one of the reasons why.
Github's dependabot provides a convenient and automatic way of bumping dependencies and making sure they're up to date.
The way it does it, it loads https://proxy.golang.org:443/github.com/rivo/tview/@v/list which is empty since there're no releases yet, and therefore doesn't found anything it can switch the dependency to. So Dependabot won't update the tview automatically without releases.

The other reason is just to follow convenient best practices that community got used to :) I would really appreciate if tview has releases with changelog!

@mih-kopylov commented on GitHub (Jan 24, 2023): @rivo I'm also interested in semantic versions. And here's one of the reasons why. Github's dependabot provides a convenient and automatic way of bumping dependencies and making sure they're up to date. The way it does it, it loads https://proxy.golang.org:443/github.com/rivo/tview/@v/list which is empty since there're no releases yet, and therefore doesn't found anything it can switch the dependency to. So Dependabot won't update the `tview` automatically without releases. The other reason is just to follow convenient best practices that community got used to :) I would really appreciate if `tview` has releases with changelog!

kerem commented

2026-03-04 01:06:12 +03:00

Author

Owner

@SamWhited commented on GitHub (Jan 24, 2023):

We have the same issue with several tools we use (they expect a release tag and don't support the fake version format). Technically this is a problem with those tools, but it would still be much nicer and we'd have to jump through fewer hoops if there were a v0.0.1 release or something. It's bitten us a number of times in a number of different ways at this point.

@SamWhited commented on GitHub (Jan 24, 2023): We have the same issue with several tools we use (they expect a release tag and don't support the fake version format). Technically this is a problem with those tools, but it would still be much nicer and we'd have to jump through fewer hoops if there were a v0.0.1 release or something. It's bitten us a number of times in a number of different ways at this point.

kerem commented

2026-03-04 01:06:12 +03:00

Author

Owner

@SamWhited commented on GitHub (Feb 24, 2023):

A quick follow up to my earlier comment because I just ran into another issue that would at least partially be solved by using semver correctly:

I just went to build a project and needed a slightly newer feature of tview. I updated, but it pulled in a breaking change to one of the interfaces, breaking my build. If the project had been using semver I could have updated to the latest version that was still minor-version compatible. Of course, mistakes could still be made, but at least I'd have an easy way to try out different versions instead of having to go dig around and find commit IDs.

I'm still really sorry to see tview not using version numbers, it looks bad in my go.mod file (not that this matters, really) and has caused me a lot of grief with tooling. I know you don't like it, but your users will thank you.

@SamWhited commented on GitHub (Feb 24, 2023): A quick follow up to my earlier comment because I just ran into another issue that would at least partially be solved by using semver correctly: I just went to build a project and needed a slightly newer feature of tview. I updated, but it pulled in a breaking change to one of the interfaces, breaking my build. If the project had been using semver I could have updated to the latest version that was still minor-version compatible. Of course, mistakes could still be made, but at least I'd have an easy way to try out different versions instead of having to go dig around and find commit IDs. I'm still really sorry to see tview not using version numbers, it looks bad in my go.mod file (not that this matters, really) and has caused me a lot of grief with tooling. I know you don't like it, but your users will thank you.

kerem commented

2026-03-04 01:06:12 +03:00

Author

Owner

@lukaszraczylo commented on GitHub (May 15, 2023):

Hi everyone,
I'm a big fan of the project, and please do not take it as an advertisement - but for the build process itself, feel free to use the semver generator ( also available as a github action to make it easier ) - https://github.com/lukaszraczylo/semver-generator
It will generate the new semantic version using config ( minor and major ) and commits ( for patch versions ), removing the headache of bumping the versions :)

@lukaszraczylo commented on GitHub (May 15, 2023): Hi everyone, I'm a big fan of the project, and please do not take it as an advertisement - but for the build process itself, feel free to use the semver generator ( also available as a github action to make it easier ) - https://github.com/lukaszraczylo/semver-generator It will generate the new semantic version using config ( minor and major ) _and_ commits ( for patch versions ), removing the headache of bumping the versions :)

kerem commented

2026-03-04 01:06:12 +03:00

Author

Owner

@rivo commented on GitHub (Jan 27, 2024):

I updated, but it pulled in a breaking change to one of the interfaces, breaking my build.

@SamWhited I would like to know what that was. A newer tview version should not break anything (subject to some minor exceptions listed in the README).

If someone has a suggestion on how to set up GitHub so it automatically version-tags every commit with an increasing patch number, that would be helpful.

@rivo commented on GitHub (Jan 27, 2024): > I updated, but it pulled in a breaking change to one of the interfaces, breaking my build. @SamWhited I would like to know what that was. A newer `tview` version should not break anything (subject to some minor exceptions listed in the README). If someone has a suggestion on how to set up GitHub so it automatically version-tags every commit with an increasing patch number, that would be helpful.

kerem commented

2026-03-04 01:06:13 +03:00

Author

Owner

@SamWhited commented on GitHub (Sep 8, 2024):

Sorry, missed this comment but I Just showed up to comment again so I can at least answer it this time: I just went to upgrade and a bunch of my structs no longer implement tview.Primitive because the PasteHandler method was added at some point (among other things, I have a rather long list of errors when I try to build with the newest version).

Please don't just automatically add patch numbers, just tag a release when one is needed, not every single time, otherwise we'll just wind up with a breaking change in a minor patch version and it won't actually help solve this problem.

At this point I am outright on my knees begging, please add a version number. This is still a frequent source of problems in my project, and it's pretty easy to do a git tag v0.0.whatever on occasion and especially when making a breaking change.

@SamWhited commented on GitHub (Sep 8, 2024): Sorry, missed this comment but I Just showed up to comment again so I can at least answer it this time: I just went to upgrade and a bunch of my structs no longer implement tview.Primitive because the PasteHandler method was added at some point (among other things, I have a rather long list of errors when I try to build with the newest version). Please don't just automatically add patch numbers, just tag a release when one is needed, not every single time, otherwise we'll just wind up with a breaking change in a minor patch version and it won't actually help solve this problem. At this point I am outright on my knees *begging*, please add a version number. This is still a frequent source of problems in my project, and it's pretty easy to do a `git tag v0.0.whatever` on occasion and especially when making a breaking change.

kerem commented

2026-03-04 01:06:13 +03:00

Author

Owner

@dolanor commented on GitHub (Mar 17, 2025):

Hi, I have an example which took me a few minutes to figure out what was breaking.

~/src/beholder$ go run .
# github.com/dhleong/beholder/src/ui/tui
src/ui/tui/async-textview.go:273:18: cannot use tview.Styles.PrimaryTextColor (variable of uint64 type "github.com/gdamore/tcell/v2".Color) as "github.com/gdamore/tcell".Color value in struct literal
src/ui/tui/async-textview.go:794:13: cannot use screen (variable of interface type "github.com/gdamore/tcell".Screen) as "github.com/gdamore/tcell/v2".Screen value in argument to t.Box.Draw: "github.com/gdamore/tcell".Screen does not implement "github.com/gdamore/tcell/v2".Screen (missing method ChannelEvents)
src/ui/tui/async-textview.go:1017:9: cannot use t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {…}) (value of type func(*"github.com/gdamore/tcell/v2".EventKey, func(p tview.Primitive))) as func(event *"github.com/gdamore/tcell".EventKey, setFocus func(p tview.Primitive)) value in return statement
src/ui/tui/async-textview.go:1017:28: cannot use func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {…} (value of type func(event *"github.com/gdamore/tcell".EventKey, setFocus func(p tview.Primitive))) as func(*"github.com/gdamore/tcell/v2".EventKey, func(p tview.Primitive)) value in argument to t.WrapInputHandler
src/ui/tui/entity-list.go:120:4: cannot use screen (variable of interface type "github.com/gdamore/tcell".Screen) as "github.com/gdamore/tcell/v2".Screen value in argument to tview.Print: "github.com/gdamore/tcell".Screen does not implement "github.com/gdamore/tcell/v2".Screen (missing method ChannelEvents)
src/ui/tui/entity-list.go:121:21: cannot use tcell.ColorDefault (constant -1 of int32 type "github.com/gdamore/tcell".Color) as "github.com/gdamore/tcell/v2".Color value in argument to tview.Print

I was just trying to play with this: https://github.com/dhleong/beholder

But the fact that tview started using a new version of tcell without any sort of versioning make this break.
I thought at first it was a problem of the project itself not using modules, but when adding them, it automatically pulled the tcell/v2 because tview does. But then, this previous code can't work.

Now, I need to dig in tview git log to find a commit that is around this original repo date and pin it in the go.mod.
Having not directly played with either of these projects, it's not great.

EDIT: I tried to downgrade, but now I have an issue in the tview codebase.

go: downloading github.com/rivo/tview v0.0.0-20201110193117-dfcd0cb598c5
go: downgraded github.com/rivo/tview v0.0.0-20241227133733-17b7edb88c57 => v0.0.0-20201110193117-dfcd0cb598c5
~/src/beholder$ go run .
# github.com/rivo/tview
../../go/pkg/mod/github.com/rivo/tview@v0.0.0-20201110193117-dfcd0cb598c5/util.go:56:12: undefined: runewidth.ZeroWidthJoiner

So now, it seems tview had a commit that was not good because there was some undefined type, but I chose it because I can't figure out which commit is release material or not and just needed a commit before the date of the last original project commit.

My solution would be to point to a tview clone instead of the module directly, and run a git bisect that would try to build the original project. But it is a lot when I just wanted to try out a tool quickly.

@dolanor commented on GitHub (Mar 17, 2025): Hi, I have an example which took me a few minutes to figure out what was breaking. ``` ~/src/beholder$ go run . # github.com/dhleong/beholder/src/ui/tui src/ui/tui/async-textview.go:273:18: cannot use tview.Styles.PrimaryTextColor (variable of uint64 type "github.com/gdamore/tcell/v2".Color) as "github.com/gdamore/tcell".Color value in struct literal src/ui/tui/async-textview.go:794:13: cannot use screen (variable of interface type "github.com/gdamore/tcell".Screen) as "github.com/gdamore/tcell/v2".Screen value in argument to t.Box.Draw: "github.com/gdamore/tcell".Screen does not implement "github.com/gdamore/tcell/v2".Screen (missing method ChannelEvents) src/ui/tui/async-textview.go:1017:9: cannot use t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {…}) (value of type func(*"github.com/gdamore/tcell/v2".EventKey, func(p tview.Primitive))) as func(event *"github.com/gdamore/tcell".EventKey, setFocus func(p tview.Primitive)) value in return statement src/ui/tui/async-textview.go:1017:28: cannot use func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {…} (value of type func(event *"github.com/gdamore/tcell".EventKey, setFocus func(p tview.Primitive))) as func(*"github.com/gdamore/tcell/v2".EventKey, func(p tview.Primitive)) value in argument to t.WrapInputHandler src/ui/tui/entity-list.go:120:4: cannot use screen (variable of interface type "github.com/gdamore/tcell".Screen) as "github.com/gdamore/tcell/v2".Screen value in argument to tview.Print: "github.com/gdamore/tcell".Screen does not implement "github.com/gdamore/tcell/v2".Screen (missing method ChannelEvents) src/ui/tui/entity-list.go:121:21: cannot use tcell.ColorDefault (constant -1 of int32 type "github.com/gdamore/tcell".Color) as "github.com/gdamore/tcell/v2".Color value in argument to tview.Print ``` I was just trying to play with this: https://github.com/dhleong/beholder But the fact that tview started using a new version of tcell without any sort of versioning make this break. I thought at first it was a problem of the project itself not using modules, but when adding them, it automatically pulled the tcell/v2 because tview does. But then, this previous code can't work. Now, I need to dig in tview git log to find a commit that is around this original repo date and pin it in the go.mod. Having not directly played with either of these projects, it's not great. EDIT: I tried to downgrade, but now I have an issue in the tview codebase. ```~/src/beholder$ go get github.com/rivo/tview@dfcd0cb598c52ce6a72ab37b49c8f2e205d810c1 go: downloading github.com/rivo/tview v0.0.0-20201110193117-dfcd0cb598c5 go: downgraded github.com/rivo/tview v0.0.0-20241227133733-17b7edb88c57 => v0.0.0-20201110193117-dfcd0cb598c5 ~/src/beholder$ go run . # github.com/rivo/tview ../../go/pkg/mod/github.com/rivo/tview@v0.0.0-20201110193117-dfcd0cb598c5/util.go:56:12: undefined: runewidth.ZeroWidthJoiner ``` So now, it seems tview had a commit that was not good because there was some undefined type, but I chose it because I can't figure out which commit is release material or not and just needed a commit before the date of the last original project commit. My solution would be to point to a tview clone instead of the module directly, and run a git bisect that would try to build the original project. But it is a lot when I just wanted to try out a tool quickly.

kerem commented

2026-03-04 01:06:13 +03:00

Author

Owner

@Stogas commented on GitHub (May 31, 2025):

I'd agree with the commenters above, in that most projects in the wild follow the SemVer convention and that sets an industry standard.

https://github.com/rivo/tview/issues/788#issuecomment-1374406006

Semantic Versioning versus your pattern:
v1.2.0 versus v0.0.0-20221128165837-db36428c92d9
v1.2.1 versus v0.0.0-20230104153304-892d1a2eb0da

At least for me, SemVer numbering immediately let's me know what amount of changes I can expect to see when updating between these versions.

In this specific case - seeing only a patch bump - I know that it's just bug fixes, I can update blindly. If it was a minor bump - perhaps I should take a peek at the documentation / release notes? Maybe there's new features I'd be glad to use?

And naturally, a major version bump, at the very least could be a good way to track when the following promise inevitably is broken:

I try really hard to keep this project backwards compatible. Your software should not break when you upgrade tview.

@Stogas commented on GitHub (May 31, 2025): I'd agree with the commenters above, in that most projects in the wild follow the SemVer convention and that sets an industry standard. https://github.com/rivo/tview/issues/788#issuecomment-1374406006 > Semantic Versioning versus your pattern: > v1.2.0 versus v0.0.0-20221128165837-db36428c92d9 > v1.2.1 versus v0.0.0-20230104153304-892d1a2eb0da At least for me, SemVer numbering immediately let's me know what amount of changes I can expect to see when updating between these versions. In this specific case - seeing only a patch bump - I know that it's just bug fixes, I can update blindly. If it was a minor bump - perhaps I should take a peek at the documentation / release notes? Maybe there's new features I'd be glad to use? And naturally, a major version bump, at the very least could be a good way to track when the following promise inevitably is broken: > I try really hard to keep this project backwards compatible. Your software should not break when you upgrade tview.

kerem commented

2026-03-04 01:06:13 +03:00

Author

Owner

@rivo commented on GitHub (Aug 27, 2025):

https://github.com/rivo/tview/releases/tag/v0.42.0

@rivo commented on GitHub (Aug 27, 2025): https://github.com/rivo/tview/releases/tag/v0.42.0

Rows
Columns

[GH-ISSUE #788] Build Semantic Versioning Releases #577