Preview at https://forgejo.codeberg.page/@pull_185/docs/v1.19/user/semver/
@earl-warren @KaKi87 please push any modification you think relevant to this PR for a quicker turnaround, I agree in advance.
Preview ready: https://forgejo.codeberg.page/@pull_185/
@ -0,0 +2,4 @@
layout: '~/layouts/Markdown.astro'
title: Semantic version
license: 'CC-BY-SA-4.0'
---
Clarifying question: There is no original source you derive from in this specific case?
No.
@ -0,0 +7,4 @@
[SemVer](https://semver.org/spec/v2.0.0.html) allows users to understand the scope of a software update at first glance, based on the following :
- the patch number is incremented when something is fixed ;
- the minor number is incremented when something is added ;
- the major number is incremented when something is moved or removed.
Not quite.
Patch is increased for backwards-compatible bugfixes.
Minor is increased for backwards-compatible new features.
Major is increased for breaking changes.
@ -0,0 +33,4 @@
```shell
$ curl https://code.forgejo.org/api/forgejo/v1/version
{"number":"3.0.0+0-gitea-1.19.0"}
As mentioned in forgejo/forgejo#460 (comment), the returned key shouldn't be number but version, just like /api/v1/version.
I'll change this Markdown file as soon as the change in the API is done, but I wouldn't know how to do the latter myself.
Thanks
This is a cosmetic change?
What do you mean ?
Is it a requirement? I'm not aware of a standard that requires the output of such an API endpoint to be a string or a dict with a specific key.
It isn't a requirement, but it's logical, isn't it ?
Most APIs do use version as key for a /version endpoint, so does Gitea's, and, in my opinion, so should ours.
Changing the key is a breaking change and it is too late for that kind of improvement for v1.19.
Can you open an issue to discuss this further?
Okay.
@KaKi87 do you approve of this pull request?
@KaKi87 do you approve of this pull request?
My opinion is that v3.0.0 shouldn't be released without changing the version endpoint's key.
Does that point factors in the approval ?
If yes, then no, I don't approve this PR.
If no, then yes, I do approve this PR.
@KaKi87 Ok, thanks for the feedback. This issue will be discussed in v1.20.
No due date set.
No dependencies set.
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?