Use Golang 1.18 for Gitea 1.17 release

[wxiaoguang]

Use Golang 1.18 (as minimal requirement) for Gitea 1.17 release, make sure the Golang version is still actively supported during Gitea 1.17 lifecycle.

And Gitea can start using Golang generics from then on.
update: As discussed in #19917 (comment) , only use it when it's carefully designed.

---

(sorry for that I opened a similar issue and opened this PR, I was going to ask to delete the issue, but soon it contains more important information 😂)

[zeripath]

Agreed with using 1.18 - Disagree with adding generics directly to gitea1.17.

We need to get 1.17 ready for release - adding generics refactors is going to delay that.

Get RC1 out then we can think about adding in Generics. (But please be aware of the caveats with their current implementation in the golang runtime - They are not free and may come with serious costs where interface{} is used.)

[delvh]

@zeripath What about releasing 1.17 as soon as possible and then backporting refactoring PRs once they appear?

[zeripath]

@zeripath What about releasing 1.17 as soon as possible and then backporting refactoring PRs once they appear?

Generally we should avoid backporting refactoring PRs as they often come with bugs and or change of behaviour. However, I think if there were something that would need backporting that included generics then having 1.17 run go1.18 would allow us to consider backporting those generics to avoid having to completely restructure that backport if necessary. I expect most of the time though, that making a non-generic backport would be easy so we shouldn't need to backport generics.

If it were getting too difficult to backport things we should just consider releasing 1.18 quickly as really our releases are too long and too big and we're making our lives difficult because of this.

[delvh]

If it were getting too difficult to backport things we should just consider releasing 1.18 quickly as really our releases are too long and too big and we're making our lives difficult because of this.

Strongly agree, but that's a completely different topic that we should tackle soon.

[lafriks]

shouldn't go mod tidy also changed without compat 1.17 flag than?

[wxiaoguang]

shouldn't go mod tidy also changed without compat 1.17 flag than?

Do you mean these code?

.PHONY: tidy
tidy:
	$(eval MIN_GO_VERSION := $(shell grep -Eo '^go\s+[0-9]+\.[0-9.]+' go.mod | cut -d' ' -f2))
	$(GO) mod tidy -compat=$(MIN_GO_VERSION)

It's already automated to parse go.mod.

[6543]

I hope all package maintainer do have enough time to prepare for that ...
... but it's a good move to use new libs who do relay on generics :)

[wxiaoguang]

I hope all package maintainer do have enough time to prepare for that ... ... but it's a good move to use new libs who do relay on generics :)

Recently I wrote another CopyMap in #17624, then I remembered the generic again 😂