starred/tview

Fork 0

mirror of https://github.com/rivo/tview.git synced 2026-04-26 21:35:54 +03:00

[GH-ISSUE #750] Dependency requires go 1.18 #549

New issue

Closed

opened 2026-03-04 01:05:55 +03:00 by kerem · 5 comments

kerem commented

2026-03-04 01:05:55 +03:00

Owner

Originally created by @Thiryn on GitHub (Aug 1, 2022).
Original GitHub issue: https://github.com/rivo/tview/issues/750

Hi, it looks like the dependency github.com/rivo/uniseg v0.3.1 requires go 1.18, which makestview requiring 1.18 too.
Building with older version won't compile because of the use of generics in uniseg.

Originally created by @Thiryn on GitHub (Aug 1, 2022). Original GitHub issue: https://github.com/rivo/tview/issues/750 Hi, it looks like the dependency `github.com/rivo/uniseg v0.3.1` requires go 1.18, which makes`tview` requiring 1.18 too. Building with older version won't compile because of the use of generics in `uniseg`.

kerem closed this issue

2026-03-04 01:05:55 +03:00

kerem commented

2026-03-04 01:05:56 +03:00

Author

Owner

@rivo commented on GitHub (Aug 1, 2022):

That's correct. (It's not just the generics, rivo/uniseg also uses the new build tag syntax.)

Go 1.18 has been out since March 2022.

@rivo commented on GitHub (Aug 1, 2022): That's correct. (It's not just the generics, `rivo/uniseg` also uses the new build tag syntax.) Go 1.18 has been out since March 2022.

kerem commented

2026-03-04 01:05:56 +03:00

Author

Owner

@Thiryn commented on GitHub (Aug 1, 2022):

Yep, that's not the problem. I just wanted to note that tview's go.mod indicates go 1.12 compatibility.

As a side note, usually utility libraries are better to be kept at an older version to allow users with older compilers to still use the library.

@Thiryn commented on GitHub (Aug 1, 2022): Yep, that's not the problem. I just wanted to note that tview's go.mod indicates go 1.12 compatibility. As a side note, usually utility libraries are better to be kept at an older version to allow users with older compilers to still use the library.

kerem commented

2026-03-04 01:05:56 +03:00

Author

Owner

@rivo commented on GitHub (Aug 1, 2022):

I just wanted to note that tview's go.mod indicates go 1.12 compatibility.

I understand. I've just updated it to 1.18.

I don't really know why Go doesn't update this automatically based on the compatibility versions found in included packages. In this case, rivo/uniseg is also my package so I know what happened. But I won't know about this for all the other packages that I'm using.

As a side note, usually utility libraries are better to be kept at an older version to allow users with older compilers to still use the library.

Is there a "grace period" maintainers should adhere to? If so, what is it? I mean, Go 1.19 is expected to be released this month.

I also wonder about people's reasons to keep using old versions. I've had someone complain about this who was using Go 1.15 which was from Feb 2021. I understand it takes a bit of time to upgrade versions. But a year and a half? Especially when there is no downside to upgrading Go.

At the same time, people can also remain on the older tview version if they have no way of upgrading Go.

@rivo commented on GitHub (Aug 1, 2022): > I just wanted to note that tview's go.mod indicates go 1.12 compatibility. I understand. I've just updated it to 1.18. I don't really know why Go doesn't update this automatically based on the compatibility versions found in included packages. In this case, `rivo/uniseg` is also my package so I know what happened. But I won't know about this for all the other packages that I'm using. > As a side note, usually utility libraries are better to be kept at an older version to allow users with older compilers to still use the library. Is there a "grace period" maintainers should adhere to? If so, what is it? I mean, Go 1.19 is expected to be released this month. I also wonder about people's reasons to keep using old versions. I've had someone complain about this who was using Go 1.15 which was from Feb 2021. I understand it takes a bit of time to upgrade versions. But a year and a half? Especially when there is no downside to upgrading Go. At the same time, people can also remain on the older `tview` version if they have no way of upgrading Go.

kerem commented

2026-03-04 01:05:56 +03:00

Author

Owner

@SamWhited commented on GitHub (Aug 1, 2022):

Is there a "grace period" maintainers should adhere to? If so, what is it? I mean, Go 1.19 is expected to be released this month.

The Go team only supports two versions of Go, right now that's Go 1.18 and Go 1.17 (when Go 1.19 comes out, support for 1.17 will be dropped). A lot of Go projects follow this rule and only support the current and previous version of Go. This is effectively a 6 month grace period.

I also wonder about people's reasons to keep using old versions.

People often keep older versions because popular Linux distros have their own support periods and may support older versions of Go. 1.12 seems a bit excessive, but I know some projects support whatever version Debian supports.

@SamWhited commented on GitHub (Aug 1, 2022): > Is there a "grace period" maintainers should adhere to? If so, what is it? I mean, Go 1.19 is expected to be released this month. The Go team only supports two versions of Go, right now that's Go 1.18 and Go 1.17 (when Go 1.19 comes out, support for 1.17 will be dropped). A lot of Go projects follow this rule and only support the current and previous version of Go. This is effectively a 6 month grace period. > I also wonder about people's reasons to keep using old versions. People often keep older versions because popular Linux distros have their own support periods and may support older versions of Go. 1.12 seems a bit excessive, but I know some projects support whatever version Debian supports.

kerem commented

2026-03-04 01:05:56 +03:00

Author

Owner

@rivo commented on GitHub (Aug 1, 2022):

@SamWhited Got it, thanks. I didn't know this. As for the issue at hand, I guess this August (until 1.19 is out) I'll be going against the Go team's habit then.

It's a bit of an exception because Go 1.18 came with Generics which is a major change, and one of the additions to rivo/uniseg greatly benefited from that. I don't think it will be like this for every future Go version.

I know some projects support whatever version Debian supports.

I understand. I use Debian, too, but since I know that it's usually always way behind and Go is so easy to install, I tend to install the latest version myself (or cross-compile). But I get why a casual user wouldn't want to do that.

@rivo commented on GitHub (Aug 1, 2022): @SamWhited Got it, thanks. I didn't know this. As for the issue at hand, I guess this August (until 1.19 is out) I'll be going against the Go team's habit then. It's a bit of an exception because Go 1.18 came with Generics which is a major change, and one of the additions to `rivo/uniseg` greatly benefited from that. I don't think it will be like this for every future Go version. > I know some projects support whatever version Debian supports. I understand. I use Debian, too, but since I know that it's usually always way behind and Go is so easy to install, I tend to install the latest version myself (or cross-compile). But I get why a casual user wouldn't want to do that.