/api/forgejo/v1/version should return a version key #545
It's logical because :
version as key for a /version endpoint ;Thanks
I sent a pull request to do that. @KaKi87 could you please take care of updating the release notes as well? This is a breaking change and needs to be documented. You have me convinced this is the right thing to do, even though it is late in the v1.19 release cycle.
could you please take care of updating the release notes as well?
Do you mean this file ? There's nothing about v3.0.0 in there 🤔
I mean here
https://codeberg.org/forgejo/forgejo/src/branch/forgejo/RELEASE-NOTES.md#1-19-0-2
There is nothing about semver yet. But since a breaking change is introduced, there must be.
Why is is there a build number (2) for a version that hasn't been built yet ?
Actually, you already wrote a something about SemVer here.
Although :
In addition to the Forgejo release number, a semantic version number can be obtained
The semantic version is the Forgejo version, while the other one is the Gitea version.
Why are all website links using v1.19 instead of v3.0.0 ??
Why is is there a build number (
2) for a version that hasn't been built yet ?
For the purpose of ordering.
Actually, you already wrote a something about SemVer here.
True: I forgot.
Although :
In addition to the Forgejo release number, a semantic version number can be obtained
The semantic version is the Forgejo version, while the other one is the Gitea version.
Not yet. The Forgejo version is still not SemVer. A SemVer is provided by this API endpoint but not yet used elsewhere.
For the purpose of ordering.
X.Y.Z is lexicographically lower than X.Y.Z-rc1 is is considered greater
If this presently matters in any way, it no longer will once using SemVer, because there's a normalized comparison algorithm.
The Forgejo version is still not SemVer.
Then why publishing this feature at all ?
As a reminder, the purpose of SemVer is to : allow users to understand the scope of a software update at first glance.
Until this goal is achieved, there's no point in publishing this feature.
New proposal :
Then why publishing this feature at all ?
If I write a script using Forgejo, I can use the API endpoint to get a SemVer and rely on it.
For now there would be no difference between using Gitea's endpoint and Forgejo's endpoint since there won't be two Forgejo releases using the same Gitea version until tags are using Forgejo's version.
After
3.0.0+0-gitea-1.19.0
there may be:
3.0.1+0-gitea-1.19.1
or
3.1.0+0-gitea-1.19.1`
or even
4.0.0+0-gitea-1.19.1
depending on what the release contains: it carries valuable information in itself.
Of course, but that's not possible until step 2, otherwise all that the users will see is 1.19.1.
The user can download Forgejo version 1.19.1-0 and the Forgejo API of that binary can show 3.1.0+0-gitea-1.19.1 (or similar). I find that useful.
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
Archived
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?