Adopt Semver

[silverwind]

Feature Description

I think it would be good to adopt semver for gitea versioning, e.g. the current minor releases would become major ones, signifying the breaking changes contained in these releases. So next version would be 2.0.0, a feature after that would be 2.1.0 and a bugfix-only release after that 2.1.1.

[denyskon]

If I understand correctly, releasing major versions in Go means effectively creating a new module every time... this does sound like something that would make our workflow harder

https://go.dev/doc/modules/release-workflow#breaking

[silverwind]

Yes, some script would be needed to rewrite the go imports, but imho just because the language makes it hard to do major bumps, it's no excuse to not do it.

[techknowlogick]

pinging @jolheiser as he had some thoughts on this as well.

[lunny]

1.21.x -> 21.x.x
1.22.x -> 22.x.x

[wxiaoguang]

I ever wrote some drafts (when Gitea is at 1.19 stage), maybe it's time to share them 😁

---

At the moment, although Gitea's version is "1.19" or "1.20", it's not a semantic version.

There are some problems:

1. It confuses with "Golang" version (that's also 1.19/1.20 ....)
2. It make people suppose that "1.x" is the same, however, each "minor" release changes a lot
3. It's difficult to make people know when a version is released.

Possible alternatives

Date versioning system

That's also what many large applications do:

For example: Year.ReleaseNumber.PatchFix-suffix

• 2023.1.0-rc0

• 2023.1.1

• 2023.4.5

• It could still be parsed by semantic version.

• The same Year.ReleaseNumber doesn't break.

• In year 2024, the release "2023.4" could still get new patch-fix releases

Switch to semantic version

Just like Java / Chrome, increase the major number: 1.19.2 -> 19.2

[jolheiser]

There is no reason we would need to change the Go imports, to the best of my knowledge.

Gitea is not installable via go install due to our build process, nor is it a valid dependency such that anyone would reasonably go get it, so there is no reason (aside from Go convention) to version the module in compliance with SIV.

EDIT: Due to the replace directives in our module, neither go get or go install will work (correctly) regardless of the above reasons.

[silverwind]

One benefit semver brings is being able to picture features in the version which previously was not possible with just two numbers where it was only major+patch. Not sure if we'd really need it thought, but I guess it's good to have an option to make a minor release if a feature warrants it.

[denyskon]

There is no reason we would need to change the Go imports, to the best of my knowledge.

Gitea is not installable via go install due to our build process, nor is it a valid dependency such that anyone would reasonably go get it, so there is no reason (aside from Go convention) to version the module in compliance with SIV.

EDIT: Due to the replace directives in our module, neither go get or go install will work (correctly) regardless of the above reasons.

Well we discovered that gitness imports some of our internal packages directly iirc. But is it something we should be bothered about?

[jolheiser]

But is it something we should be bothered about?

No, and even then they can still import it, it will just be marked incompatible (with SIV) in their module.

[inferenceus]

Semantic Versioning is important, especially because it's standardised. While it's not terrible how Gitea currently does its versioning, SemVer would be a huge benefit.

[silverwind]

One problem is golang makes it far too hard to have proper semver. Ever wondered why almost all go projects are at v1 while having done many breaking changes? golang's stupid requirement of having the version in the module path is the reason:

https://donatstudios.com/Go-v2-Modules
golang/go#31543

[jolheiser]

One problem is golang makes it far too hard to have proper semver. Ever wondered why almost all go projects are at v1 while having done many breaking changes? golang's stupid requirement of having the version in the module path is the reason:

donatstudios.com/Go-v2-Modules golang/go#31543

This isn't a problem for us, see #27574 (comment)

[silverwind]

One problem is golang makes it far too hard to have proper semver. Ever wondered why almost all go projects are at v1 while having done many breaking changes? golang's stupid requirement of having the version in the module path is the reason:
donatstudios.com/Go-v2-Modules golang/go#31543

This isn't a problem for us, see #27574 (comment)

Would we still need to rewrite all internal imports on every major bump or could we circumvent that with a replace directive in go.mod?

[jolheiser]

Neither would be required. The module version only matters for other Go ecosystem things to interact with us, which is already impossible due to other factors or is extremely unlikely.

That is to say, yes we would technically not be following Go's versioning for SIV, but SIV is only enforced if your project is expected to be interacted with as a dependent, i.e. go get, go install, go run, etc etc.
We are none of the above and likely won't be any time soon, if ever.

---

Also as a quick aside since it was mentioned earlier in the thread, Gitness no longer depends on (a very outdated version of) us as of a few weeks ago - harness/harness@cecfecd.

[silverwind]

Neither would be required. The module version only matters for other Go ecosystem things to interact with us, which is already impossible due to other factors or is extremely unlikely.

I thought golang would basically break as soon as module version does not match git version, but I guess go itself can and must work without a git dependency, so therefor it should never read the git tag info. I wouldn't be so sure whether this won't change in the future, thought.

That is to say, yes we would technically not be following Go's versioning for SIV,

What is SIV? Sorry, not familiar with that term.

[jolheiser]

SIV is semantic import versioning, e.g. requiring the module path to include /vN

Go works with many VCS, not just git, so it can never truly rely on git-specific information. We also don't use any of the internal VCS info, so no breakage there.

The things that break are essentially non-issues for us because we aren't a library and because we already aren't feasible for other reasons.

At this point Gitea is only part of the Go ecosystem in language, more or less. Nothing can feasibly depend on our module, and we require a build step so install and run are out.

[jolheiser]

We could (and should) test it out beforehand in a duplicate repo to iron out release kinks, etc.