gitea: Recent Gitea 1.16 (stable) breaks build on Fedora 35 because the go.mod was changed to require Go1.17
Description
I can no longer build the stable branch 1.16 on my Fedora 35 system.
go mod tidy fails, see below.
+ make 'TAGS=bindata sqlite sqlite_unlock_notify pam' 'LDFLAGS=-X "code.gitea.io/gitea/modules/setting.AppWorkPath=/var/lib/gitea" -X "code.gitea.io/gitea/modules/setting.CustomPath=/var/lib/gitea/custom" -X "code.gitea.io/gitea/modules/setting.PIDFile=/run/gitea/gitea.pid" -X "code.gitea.io/gitea/modules/setting.CustomConf=/etc/gitea/app.ini"' vendor build
go mod tidy && go mod vendor
go mod tidy: go.mod file indicates go 1.17, but maximum supported version is 1.16
make: *** [Makefile:374: vendor] Error 1
IMHO The stable branch should not break existing working setups.
Gitea Version
1.16
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
f9ea4ab69ae397be4791c2e2ebf59f6cd9e5a6f8
Operating System
Fedora 35 x64
How are you running Gitea?
not relevant
Database
PostgreSQL
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 33 (25 by maintainers)
OK. If nobody against that, let’s change go.mod to go 1.16 in Gitea v1.16.6 but add a warning in Makefile if go version less than 1.17.
Right yes, I understand and I agree. I understand the importance of following upstream as close as possible. As a question to the rest of the gitea development team I have to ask though, 1.16 for gitea is the current stable branch, is it not? Seems odd to me to raise the minimum golang version in a stable branch rather than planning for it in a development capacity (eg for 1.17), which unfortunately breaks a lot of builds.
Reason I say this is a good chunk of stable distributions provide golang packages to their users and do not upgrade them right away (on top of using binaries from go.dev is a non-starter). For example, RHEL does large rebases every 6 months (RHEL 8.6 won’t be released till May, which will have 1.17). Fedora, unless the maintainers have a reason, do not generally rebase versions in their current release. 1.18 for example is being built for Fedora 36 beta, and it is unlikely that it will come down to Fedora 35. There’s no indication of this happening, at least from their maintainers.
I understand the development styles and plans are different from project to project in open source. It’s these decisions though that just makes it difficult for users who are confined to what they have from their distribution if they wish to build gitea in a certain way (like having PAM support). And for some of us users, downloading directly from go.dev is typically a non-starter in some capacities.
Hopefully we can get some input and some information for myself and others who may be running into this issue.
I think for official Gitea binary, we should keep it security ASAP. For those want(have to) compile Gitea themselves, we should allow them to do that. But we can detect go version and have a warning when users compile Gitea with a lower version of Go. The change could be in Makefile.
Hey, sorry for all the trouble this has caused. This is entirely on me, I was rush in fixing go1.18 issues and trying to release a security release at the same time that I removed support for go1.16. When precedence states, as with all other releases we don’t bump minimum go version for a release branch (although we may start building it with newer versions, but still leaving that older versions of go for people to build themselves). Hopefully the linked PR can be applied as a patch to the fedora release until we can cut another 1.16.x release.
Raising the required go version is a breaking change, this requires at least a new minor version, something like that should NEVER be done within a patch release.