search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.21k stars 5.5k forks source link

Adopt Semver #27574

Open silverwind opened 1 year ago

silverwind commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

lunny commented 1 year ago

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

wxiaoguang commented 1 year ago

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

Switch to semantic version

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

jolheiser commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 8 months ago

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 commented 7 months ago

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 https://github.com/golang/go/issues/31543

jolheiser commented 7 months ago

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 https://github.com/go-gitea/gitea/issues/27574#issuecomment-1757729006

silverwind commented 7 months ago

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 commented 7 months ago

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 - https://github.com/harness/gitness/commit/cecfecdb060e189e545294c3c431efc58a45ae16.

silverwind commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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