Recent Gitea 1.16 (stable) breaks build on Fedora 35 because the go.mod was changed to require Go1.17

[fhuberts]

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

f9ea4ab

Operating System

Fedora 35 x64

How are you running Gitea?

not relevant

Database

PostgreSQL

[fhuberts]

Commit f9ea4ab breaks it

[nazunalika]

I'm also seeing this issue. I build gitea RPM's in copr and I attempted to patch it for Fedora 35 and RHEL 8 as both fail but without success. CentOS Stream 8 and Fedora 36 are unaffected.

I believe raising to minimum golang 1.17 wasn't the right move on the stable branch.

[wxiaoguang]

Golang doesn't think so, you see: https://go.dev/dl/ , you can only find go 1.17 and 1.18 now.

[fhuberts]

That is all fine and dandy, but you're breaking builds on the stable branch.
Please please revert back to go 1.16.

[wxiaoguang]

That is all fine and dandy, but you're breaking builds on the stable branch. Please please revert back to go 1.16.

I just tried to answer why, but I am not the decision maker, it needs the team to decide ......

[nazunalika]

Golang doesn't think so ... you can only find go 1.17 and 1.18 now

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.

[wxiaoguang]

Personally, I am neutral to such break (neither support nor objection). I understood how it matters and understand your points.

Why I don't treat it as not right because Gitea isn't a framework, and it doesn't promise to follow Linux distribution lifecycles. And Gitea can always be complied to binaries for all distributions (eg: use docker to compile), and you can always build it and run it for Fedora 35, in the end, there is no breaking.

And I agree that we can not say that it is not wrong because it indeed changes something for build, and it would cause problems for legacy system which uses shared build (I am not sure whether there is really such build, if yes, I believe the Gitea team should pay more attentions)

Take a real case for example, as a Debian user, Debian 11 only provides Golang1.15, does it mean that recent Gitea doesn't work for Debian? So my personal feeling is that since Gitea is an app, as long it as can be compiled and run correctly, then it could not be a serious break.

ps: to make the issue more clean, I edited the title to reflect the real topic, I think it needs to be decided by the maintainers and owners.

ps: ps: There is a drawback if the Gitea stable branch always uses the old Golang: it would never receive security patches from Golang, it might be a problem: https://go.dev/doc/devel/release#policy : "Each major Go release is supported until there are two newer major releases.", no more security fixes for old releases.

[42wim]

@fhuberts If you really want to build with 1.16, you can manually change the go.mod or run go mod tidy -go=1.16 (it works for now until some dependent library start requiring go 1.17 or go 1.18

But I agree with @wxiaoguang as Go security updates only supports the 2 most recent versions Gitea should always be on one of the latest major releases.

Fedora and Go have both 6 month release cycles and this seems to cause this sort of issues. It looks like F36 will have go 1.18 though :)

[fhuberts]

I understand all of the arguments.
However, you're making it much harder for gitea to be adopted by distributions when you do it like this.

You have only 1 stable branch and you're breaking things on it.
For distributions that is a huge NO NO, blocking adoption.

If you want to break stuff, you should create a new stable branch and break stuff there.
In this case, a 1.17 branch should have been created right before the breaking commit.

I really like gitea and am using it heavily, but these kinds of things just make it harder.
It also means that my build server has to run the bleeding edge all the time.
Worse even: I have to run Fedora rawhide in this case if I want to pick up the bugfixes on the stable branch!
And I'm running Fedora, let's not talk about if I'd run Debian...

I do hope you see the 'strangeness' of the situation...