[Doc] Improve document about the bug fix releases before a versioned release

[wxiaoguang]

Feature Description

Gitea has first time bug fix builds/releases by

• https://dl.gitea.com/gitea/1.19/
• docker: gitea:1.19-dev

They both contain the latest bug fixes for next unreleased 1.19.x version.

For example, suppose the current latest release is 1.19.0 , the next planned release is 1.19.1 , these builds above contain all bug fixes for 1.19.1 until 1.19.1 gets released.

It would greatly help users who are affected by bugs. I guess not everyone knows this trick.

And, the directory naming is confusing. I guess the name should be:

• .../gitea/1.19-dev/ to match docker gitea:1.19-dev
• .../1.19/ to match docker gitea:1.19

---

Update: maybe 1.19-nightly is a better name for docker image and binary downloads

[wxiaoguang]

One more case today

• Support MINIO_CHECKSUM_ALGORITHM on lfs #23837 (comment)

[lunny]

Let me summary the proposal, we can rename both download names and docker tags.

For binaries directories:

• main -> next-nightly
• 1.19 -> 1.19-nightly
• 1.18 -> 1.18-nightly
  Others will be kept unchanged.

For docker tags:

• 1.19-dev -> 1.19-nightly
• 1.18-dev -> 1.18-nightly

For those want to follow a stable nightly version, they could use the nightly versions.

[wxiaoguang]

Maybe main -> next-nightly ?

[techknowlogick]

RFC: Update deveplopment binary name and docker image name to be consistent

Current status:

The names of the binary for the nightly builds of branches, and the docker image name aren't the same. This has created at least several support requests even in the last week. The -dev prefix, used in the docker image name, appears to not be clear to users that it is the latest commit to the release branch, and on the downloads site, the -dev prefix is not used and is kept at 1.x for the latest nightly build for a branch.

Proposal:

Use nightly as the suffix for the binary name, and the docker image name to keep consistency between the two. This will also make it easier to identify the nightly builds from the stable builds.

Implementation:

Drone would to updated to use the new suffix for the nightly docker builds, and the make file would need to have a suffix added to the nightly builds.

A transition period would be needed for docker images, as the old images would need to be kept around for a while to allow users to migrate to the new images. The old images would need to be updated to point to the new images, and the new images would need to be updated to point to the old images. This would allow users to migrate to the new images, and then the old images could be removed.

Redirects would need to be added to the downloads site for the nightly builds of release branches, to point to the new location nightly builds.

A page around versioning, and names would need to be added to the documentation site to explain the naming conventions, and how to identify the different builds.

Finally, we'd also need to backport the changes to the 1.19 branch so that while we are in the proccess of releasing 1.20, we can start using the new naming conventions. In addition, 1.19 might become the new LTS release, so we'd need to make sure that the naming conventions are in place.

cc: @go-gitea/maintainers could you vote 👍 or 👎

(edit: the proposal sums up the above comments from @wxiaoguang )

[6543]

I woud do main -> next rest should be as proposed

[techknowlogick]

@6533 would 1.19-dev become 1.19-next too?

[wxiaoguang]

I woud do main -> next rest should be as proposed

IMO next is not clear enough. Does it mean next major release or next minor release?

Maybe there could be some different choices:

1. Use next for major release
   • next-nightly
   • 1.19-nightly
   • 1.19.1

• OR -

2. Not use next but use branch/tag name:
   • main-nightly
   • 1.19-nightly
   • 1.19.1

Personally I prefer the second one, main-nightly , 1.19-nightly , it matches the branches and tags, people do not need to think what's the meaning of these words.

And I think it's better to make the binary downloads have exactly the same naming as docker image tags.

Just my opinion.