chore: update default version

[sapk]

I know that the version is generate in makefile but it would be good to keep it up-to-date from time to time.

Related #9913

[techknowlogick]

I think it would be better if we have this set to 0.0.0-dev, as we have our makefile override this, and then we could also distinguish better when the binary is built via go build without version info passedin.

[sapk]

-dev is already specific to direct build ?

[techknowlogick]

or maybe have it blank like the below variables?

[6543]

@techknowlogick we had this topic before ... #8686

[techknowlogick]

@6543 I just don't think this should have to be kept up to date, as makefile already gives us the info. Having it be a non version would prevent users from being confused when we don't update this line.

My opinion is still the same as the other PR you made.

[sapk]

Maybe it is time for a vote ?

• 👍 empty
• 👎 updated version (or at least from time to time)
• 😄 0.0.0-dev
• 🎉 develop
• 😕 leave as it is
• ❤️ development
• 🚀 unknown

(emojis are just listed by order and doesn't means anythings)

Edit: add development
Edit: add unknown

[codecov-io]

Codecov Report

Merging #9916 into master will not change coverage.
The diff coverage is 43.96%.

@@           Coverage Diff           @@
##           master    #9916   +/-   ##
=======================================
  Coverage   42.27%   42.27%           
=======================================
  Files         610      610           
  Lines       80370    80370           
=======================================
  Hits        33978    33978           
- Misses      42208    42210    +2     
+ Partials     4184     4182    -2

Impacted Files	Coverage Δ
models/models.go	61.71% <ø> (ø)	⬆️
services/pull/commit_status.go	5.19% <ø> (ø)	⬆️
routers/repo/http.go	38.75% <ø> (ø)	⬆️
routers/repo/setting.go	14.99% <ø> (ø)	⬆️
modules/migrations/base/downloader.go	26.66% <ø> (ø)	⬆️
routers/repo/view.go	39.47% <ø> (ø)	⬆️
routers/repo/repo.go	30.02% <ø> (ø)	⬆️
routers/api/v1/user/key.go	67.26% <ø> (ø)	⬆️
routers/api/v1/user/follower.go	0% <ø> (ø)	⬆️
routers/repo/issue_label.go	42.18% <ø> (ø)	⬆️
... and 192 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6ac6097...376c0e4. Read the comment docs.

[6543]

@go-gitea/maintainers vote: #9916 (comment)

[techknowlogick]

blocked until vote is over

[lunny]

The version is some meaning when you download the tar zip source file. Because there is no git commit information to let you know what's the version of this source copy.

[techknowlogick]

What @lunny has said makes sense. I've taken away my block.

[jolheiser]

Based on the related issue I would actually argue against updating this value unless we plan on doing so for every release.
I personally think this string should make it entirely clear that a build made without the link flags is not indicative of the actual version.

[6543]

suggestion

[guillep2k]

How about "built from sources", "please build using make" or "don't bother, it's not relevant" 🤣

No, really, some text that implies that it was built outside of the normal build flow.

[techknowlogick]

@guillep2k that’s why I had suggested 0.0.0-dev previously

[sapk]

The -dev flag imply that it was build without make.
I wasn't intending to fire up such a debat (sorry) but the vote will clear this one for all and it seems to be "develop" the winner for now.

I think it is good to close some old debat that was put aside and clear them by a vote by maintainers and not stay with a status quo.

[davidsvantesson]

@guillep2k Maybe set to something ironic, like "did-you-make-it?"

[tboerger]

For drone plugins im setting it to unknown by default

[6543]

@sapk is core not chore or ?

[sapk]

I used chore: for a non essential code change like https://www.conventionalcommits.org/en/v1.0.0/

[wxiaoguang]

I believe we need to set AppVer to valid version string now.

See:

• Set default AppVer for main branch #18146
• Integration test for migration #18124
• Integration test for migration #18124 (review)

Or, is there any better way to avoid AppVer appearing in many unit tests?