Add section describing versioning and update policy #347
No reviewers
Labels
No Label
has
backport
in progress
invalid
kind
breaking
kind
bug
kind
build
kind
dependency
kind
deployment
kind
docs
kind
enhancement
kind
feature
kind
lint
kind
proposal
kind
question
kind
refactor
kind
security
kind
testing
kind
translation
kind
ui
need
backport
priority
critical
priority
low
priority
maybe
priority
medium
reviewed
duplicate
reviewed
invalid
reviewed
wontfix
skip-changelog
status
blocked
status
needs-feedback
status
needs-reviews
status
wip
upstream
gitea
upstream
other
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/helm-chart#347
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "pat-s/helm-chart:update-policy"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
After recent discussions in Discord.
Feel free to modify as needed!
@ -14,0 +19,4 @@
The chart aims to follow Gitea's releases closely.
There might be times when the chart is behind the latest Gitea release.
This might be caused by different reasons, most often due to time constraints of the maintainers (remember, all work here is done voluntarily in the spare time of people).
If you're eager to use the latest Gitea version earlier than this chart catches up, then change the tag in `values.yml` to the latest Gitea version.
@ -14,0 +22,4 @@
If you're eager to use the latest Gitea version earlier than this chart catches up, then change the tag in `values.yml` to the latest Gitea version.
Note that besides the exact Gitea version one can also use the `:1` tag to automatically follow the latest Gitea version.
This should be combined with `image.pullPolicy: "Always"`.
Note that using the `:1` will also automatically jump to new minor release (e.g. from 1.13 to 1.14) which may eventually cause incompatibilities if major changes happened between these versions.
Do we speak of minor version bump or major version bump between 1.13 to 1.14?
I am thinking of the naming for semver
major.minor.path
but am not sure what's correct in the context of Gitea versioning.Gitea doesn't strictly follow semantic versioning as breaking changes do not increase the major version.
So in Gitea's case "minor" version bumps are actually "major". This is why I added the example to make it explicit and explain this case in more detail.
I'd also refer to it as "minor" as this is what is commonly used for the x.y.z logic. But I also see that others might do different. I think we can't discuss Gitea's general versioning approach here :D
How would you (re)phrase it?
Probably exactly how you explained.
as an addition to the sentence "Note that using the
:1
will also...."@ -14,0 +24,4 @@
This should be combined with `image.pullPolicy: "Always"`.
Note that using the `:1` will also automatically jump to new minor release (e.g. from 1.13 to 1.14) which may eventually cause incompatibilities if major changes happened between these versions.
Though most often no issues will encountered and the chart maintainers aim to communicate early if this would be the case.
You might
Loose end?
Good catch!
blocked by #355
@justusbunsi Can we merge here?
@ -14,0 +14,4 @@
## Update and versioning policy
The Gitea helm chart versioning does not follow Gitea's versioning.
The latest chart version can be looked up in [https://dl.gitea.io/charts](https://dl.gitea.io/charts) or in the [repository releases](https://gitea.com/gitea/helm-chart/releases).
Can you use dl.gitea.com instead of the .io due to the recent CDN changes?
@ -14,0 +24,4 @@
This should be combined with `image.pullPolicy: "Always"`.
Important: Using the `:1` will also automatically jump to new minor release (e.g. from 1.13 to 1.14) which may eventually cause incompatibilities if major/breaking changes happened between these versions.
This is due to Gitea not strictly following [semantic versioning](https://semver.org/#summary) as breaking changes do not increase the major version.
I.e., "minor" version bumps are actually "major".
Can you use
considered
instead ofactually
?LGTM
@techknowlogick Anything left from your side?