KaKi87 commented 2023年01月03日 21:37:39 +01:00

Introduction

SemVer 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.

something could be :

• a command, an option or an argument, for a CLI ;
• a route path, a query parameter or a body property, for a REST API ;
• a text node, a button or a field, for a GUI.

Forgejo's case

Generality

Since Forgejo has all of the above, changes to all of those components should be taken into consideration when creating a new version number.

The REST API

A major version number is specified in Forgejo's REST API's base URL (/api/v1) but was never incremented.
Multiple options are available :

Option A - Matching the REST API's version with the global version

It's actually likely that the REST API's major version number already matches the global major version number, so the former would never have been incremented simply because the latter never were either.

So, as stated in the introduction, the global major version would be incremented whenever something is moved or removed in any Forgejo component, and so would the REST API's major version.

Option B - Separately versioning the REST API

In this case, the REST API's major version number would only be incremented when something is moved or removed in the REST API, while the global major version number would remain unchanged.

However, the global major version would be incremented when an old version of the REST API would be dropped.

Option C - Removing/ignoring the REST API versioning

Since the REST API was never semantically versioned, and since the project as a whole would become semantically versioned, it could be somehow acceptable to drop separate versioning for the API :

• by removing the version number from the route path (i.e. only GET /api/user would work)
• or by ignoring whatever value is passed (i.e. GET /api/v1/user would continue to work but so would GET /api/v2/user, GET /api/v314/api/user and GET /api/whatever/user)
• and eventually making it optional (i.e. GET /api/user would also work).

Getting started

In order to actually adopt SemVer, a semantic version will eventually be created for the first time, but there are multiple options available as to where start from, exactly.

Option A - Migrate existing Forgejo versions to SemVer starting from scratch

• v1.18.0-rc0 would become v1.0.0-rc.0 ;
• v1.18.0-rc1 would become v1.0.0-rc.1 ;
• v1.18.0-rc1-1 would become v1.0.0-rc.1+1 ;
• v1.18.0-rc1-2 would become v1.0.0-rc.1+2 ;
• v1.18.0-0 would become v1.0.0+0 (or v1.0.0) ;
• v1.18.0-1 would become v1.0.0+1.

Option B - Migrate future Forgejo versions to SemVer starting from scratch

• v1.18.0-1 & older would remain as-is ;
• the next one will be v1.0.0.

Option C - Migrate existing Forgejo versions to SemVer starting from the previous Gitea version

The previous version number (1.17.4) would be incremented according to SemVer based on changes occured in the last version (i.e. 1.18.0 would remain as-is or replaced by 1.17.5 or 2.O.O).

Option D - Migrate future Forgejo versions to SemVer starting from the last Forgejo version

The last version number (1.18.0) will be incremented according to SemVer (i.e. to 1.18.1, 1.19.0 or 2.0.0).

Related discussions

• forgejo/meta#60
• forgejo/forgejo#43

---

Personally, I ordered options according to my own preferences.

Thanks

---

Progress report

Task	Issue	PR	Release
Create semantic version & /api/forgejo/v1/version endpoint returning it	#212	#242	1.19.0-0
Name binaries after semantic version	#455	-	-
Redirect tag references to Gitea version	-	-	-
Name tag after semantic version	-	-	-

# Introduction [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. *something* could be : - a command, an option or an argument, for a CLI ; - a route path, a query parameter or a body property, for a REST API ; - a text node, a button or a field, for a GUI. # Forgejo's case ## Generality Since Forgejo has all of the above, changes to all of those components should be taken into consideration when creating a new version number. ## The REST API A major version number is specified in Forgejo's REST API's base URL (`/api/v1`) but was never incremented. Multiple options are available : ### Option A - Matching the REST API's version with the global version It's actually likely that the REST API's major version number already matches the global major version number, so the former would never have been incremented simply because the latter never were either. So, as stated in the introduction, the global major version would be incremented whenever something is moved or removed in any Forgejo component, and so would the REST API's major version. ### Option B - Separately versioning the REST API In this case, the REST API's major version number would only be incremented when something is moved or removed in the REST API, while the global major version number would remain unchanged. However, the global major version would be incremented when an old version of the REST API would be dropped. ### Option C - Removing/ignoring the REST API versioning Since the REST API was never semantically versioned, and since the project as a whole would become semantically versioned, it could be somehow acceptable to drop separate versioning for the API : - by removing the version number from the route path *(i.e. only `GET /api/user` would work)* - or by ignoring whatever value is passed *(i.e. `GET /api/v1/user` would continue to work but so would `GET /api/v2/user`, `GET /api/v314/api/user` and `GET /api/whatever/user`)* - and eventually making it optional *(i.e. `GET /api/user` would also work)*. ## Getting started In order to actually adopt SemVer, a semantic version will eventually be created for the first time, but there are multiple options available as to *where* start from, exactly. ### Option A - Migrate existing Forgejo versions to SemVer starting from scratch - `v1.18.0-rc0` would become `v1.0.0-rc.0` ; - `v1.18.0-rc1` would become `v1.0.0-rc.1` ; - `v1.18.0-rc1-1` would become `v1.0.0-rc.1+1` ; - `v1.18.0-rc1-2` would become `v1.0.0-rc.1+2` ; - `v1.18.0-0` would become `v1.0.0+0` (or `v1.0.0`) ; - `v1.18.0-1` would become `v1.0.0+1`. ### Option B - Migrate future Forgejo versions to SemVer starting from scratch - `v1.18.0-1` & older would remain as-is ; - the next one will be `v1.0.0`. ### Option C - Migrate existing Forgejo versions to SemVer starting from the previous Gitea version The previous version number (`1.17.4`) would be incremented according to SemVer based on changes occured in the last version (i.e. `1.18.0` would remain as-is or replaced by `1.17.5` or `2.O.O`). ### Option D - Migrate future Forgejo versions to SemVer starting from the last Forgejo version The last version number (`1.18.0`) will be incremented according to SemVer (i.e. to `1.18.1`, `1.19.0` or `2.0.0`). ## Related discussions - [`forgejo/meta#60`](/forgejo/meta/issues/60) - [`forgejo/forgejo#43`](/forgejo/forgejo/issues/43) --- Personally, I ordered options according to my own preferences. Thanks --- ### Progress report | Task | Issue | PR | Release | | --- | --- | --- | --- | | Create semantic version & `/api/forgejo/v1/version` endpoint returning it | #212 | #242 | `1.19.0-0` | | Name binaries after semantic version | #455 | - | - | | Redirect tag references to Gitea version | - | - | - | | Name tag after semantic version | - | - | - |

Ghost commented 2023年01月03日 21:49:30 +01:00

I'm in favor of semver and my impression is that everybody agrees it is a good thing. The trick is to do that without breaking anything. During the conversation on the chat you made me realize it was less challenging than I imagined. Yet, there are roadblocks.

The first one is how to deal with the Forgejo ecosystem that has hardcoded dependencies on former and future Gitea release numbers? The first example that comes to mind is the tea client. It gets the version from the REST API and changes its behavior dependending. It does that now and future versions are likely to keep doing that for a while. If Forgejo does not comply, the tea client will stop working and we don't want that.

Any idea?

---

Option B to get started would be to move to v2.0.0 right? Not v1.0.0 which would go back in time. Or am I missing something.

I'm in favor of semver and my impression is that everybody agrees it is a good thing. The trick is to do that without breaking anything. During the conversation on the chat you made me realize it was less challenging than I imagined. Yet, there are roadblocks. The first one is how to deal with the Forgejo ecosystem that has hardcoded dependencies on former **and** future Gitea release numbers? The first example that comes to mind is the **tea** client. It gets the version from the REST API and changes its behavior dependending. It does that now and future versions are likely to keep doing that for a while. If Forgejo does not comply, the tea client will stop working and we don't want that. Any idea? --- Option B to get started would be to move to v2.0.0 right? Not v1.0.0 which would go back in time. Or am I missing something.

KaKi87 commented 2023年01月03日 22:01:50 +01:00

the tea client [...] gets the version from the REST API and changes its behavior dependending. It does that now and future versions are likely to keep doing that for a while. If Forgejo does not comply, the tea client will stop working and we don't want that.
Any idea?

We could let the existing version endpoint return the Gitea-compatible version and create a new endpoint that would return the Forgejo version.

An alternative would be to fork that client as well so it would match Forgejo versions and maybe benefit from Forgejo-specific features.

Option B to get started would be to move to v2.0.0 right? Not v1.0.0 which would go back in time. Or am I missing something.

Actually, by from scratch I meant starting with 1.0.0, the difference between options A and B being that the latter only migrates future versions while the former also migrates existing ones.

That difference causes an unpractical downgrade effect which I indeed overlooked... I guess starting from 2.0.0 is an alternative, but with that in mind I'd rather go with option D if you wouldn't go with options A or C.

> the tea client [...] gets the version from the REST API and changes its behavior dependending. It does that now and future versions are likely to keep doing that for a while. If Forgejo does not comply, the tea client will stop working and we don't want that. Any idea? We could let the existing version endpoint return the Gitea-compatible version and create a new endpoint that would return the Forgejo version. An alternative would be to fork that client as well so it would match Forgejo versions and maybe benefit from Forgejo-specific features. > Option B to get started would be to move to v2.0.0 right? Not v1.0.0 which would go back in time. Or am I missing something. Actually, by *from scratch* I meant *starting with 1.0.0*, the difference between options A and B being that the latter only migrates future versions while the former also migrates existing ones. That difference causes an unpractical downgrade effect which I indeed overlooked... I guess starting from `2.0.0` is an alternative, but with that in mind I'd rather go with option D if you wouldn't go with options A or C.

fsologureng commented 2023年01月03日 22:35:49 +01:00

If there is an easy way to define the API version decoupled from release version, I think Forgejo could start with Semver without needs of hard forking the tea cli. But for ease users with migration/upgrade I would suggest a build metadata indicating the gitea version. For example 2.0.0+gitea-1.19.0.

If there is an easy way to define the API version decoupled from release version, I think Forgejo could start with Semver without needs of hard forking the tea cli. But for ease users with migration/upgrade I would suggest a build metadata indicating the gitea version. For example `2.0.0+gitea-1.19.0`.

gapodo commented 2023年01月03日 22:39:30 +01:00

As I've stated multiple times I am in fact in favor of using SemVer, but we need to have a clear path in mind, for it to be actually usable.

Some ideas on how we could handle this would be to:

• only change SemVer on supported interfaces (i.e. if we are not breaking the supported use-case, it's not breaking)
• maintain 2 (or more?) SemVer compliant versions (one for the API used for API tooling, and another one for the binary)
  • allows keeping the API at the same version even if we break, the config, CLI or anything else, that doesn't change API behavior
  • allows us to increment the API when needed (though IMHO this should also cause a bump in the binary version, as it changes the overall compatibility)
• Have our own API endpoint, which we maintain well versioned
  • use something like api/forgejo/vX
    • keeps us clear of any changes Gitea may want to introduce (except for them maliciously taking over that endpoint, which should IMHO cause a hard fork anyway as they are at that point clearly intending on harming our work)
  • leaving api/vX be (i.e. unchanged from upstream)
    • keeps compatibility with tooling tailored towards Gitea (such as the go-sdk which is in turn used in the tea CLI client)
    • keeps Forgejo working with all code.gitea.io/sdk dependent packages... Browse here a bit to see some of it, potentially also change a version or 2 backwards to see the amount of dependent projects

Regarding where do we start... I'd tend to go with either

• v2
  • v1 is already in use and going below the current version is just wrong
  • using v1.18++ could be confusing to the user
• v10 or similar
  • start with some distance
  • use a "nice" number as the base from where work onwards
  • 10 is nice as it allows for another 89 versions before the width of the first version part changes (nicer sorting in lexicographical systems, such as the tag list, or a file manager)

Also, I'd think about using the + notation as denoting the Gitea release (for the binary, the API wouldn't need it as it's fully independent), so it stays simple to see which version a binary is based on (as long as we are based on Gitea)

---

Edit just to add a thing that just came to mind, if we more or less decouple our api, we can put it into a seperate package, which would allow us to better handle licensing as well as collision avoidance in rebases,... and also makes it easier to put out a proper API/sdk package for use in other software

As I've stated multiple times I am in fact in favor of using SemVer, but we need to have a clear path in mind, for it to be actually usable. Some ideas on how we could handle this would be to: * only change SemVer on supported interfaces (i.e. if we are not breaking the supported use-case, it's not breaking) * maintain 2 (or more?) SemVer compliant versions (one for the API used for API tooling, and another one for the binary) * allows keeping the API at the same version even if we break, the config, CLI or anything else, that doesn't change API behavior * allows us to increment the API when needed (though IMHO this should also cause a bump in the binary version, as it changes the overall compatibility) * Have our own API endpoint, which we maintain well versioned * use something like `api/forgejo/vX` * keeps us clear of any changes Gitea may want to introduce (except for them maliciously taking over that endpoint, which should IMHO cause a hard fork anyway as they are at that point clearly intending on harming our work) * leaving `api/vX` be (i.e. unchanged from upstream) * keeps compatibility with tooling tailored towards Gitea (such as the go-sdk which is in turn used in the tea CLI client) * keeps Forgejo working with all code.gitea.io/sdk dependent packages... [Browse here a bit to see some of it, potentially also change a version or 2 backwards to see the amount of dependent projects](https://deps.dev/go/code.gitea.io%2Fsdk%2Fgitea/v0.15.1/dependents) Regarding where do we start... I'd tend to go with either * v2 * v1 is already in use and going below the current version is just wrong * using v1.18++ could be confusing to the user * v10 or similar * start with some distance * use a "nice" number as the base from where work onwards * 10 is nice as it allows for another 89 versions before the width of the first version part changes (nicer sorting in lexicographical systems, such as the tag list, or a file manager) Also, I'd think about using the `+` notation as denoting the Gitea release (for the binary, the API wouldn't need it as it's fully independent), so it stays simple to see which version a binary is based on (as long as we are based on Gitea) ----- Edit just to add a thing that just came to mind, if we more or less decouple our api, we can put it into a seperate package, which would allow us to better handle licensing as well as collision avoidance in rebases,... and also makes it easier to put out a proper API/sdk package for use in other software

KaKi87 commented 2023年01月03日 23:41:13 +01:00

maintain 2 (or more?) SemVer compliant versions (one for the API used for API tooling, and another one for the binary)
allows keeping the API at the same version even if we break, the config, CLI or anything else, that doesn't change API behavior
allows us to increment the API when needed (though IMHO this should also cause a bump in the binary version, as it changes the overall compatibility)

i.e. option B, but actually we can't do that to the main API since preserving Gitea compatibility is the goal.

However, it would be a good idea for a Forgejo-specific API.

them maliciously taking over that endpoint

That seems unlikely (I hope).

where do we start... I'd tend to go with either v2

Same as @dachary.

[...] or v10 or similar.

I'm against this as our first step into SemVer compliance would be non-compliant. 😅

we can put [our API] into a seperate package

You mean creating a binary that only contains /api/vX and another that contains both /api/vX and /api/forgejo/vX ?

> maintain 2 (or more?) SemVer compliant versions (one for the API used for API tooling, and another one for the binary) allows keeping the API at the same version even if we break, the config, CLI or anything else, that doesn't change API behavior allows us to increment the API when needed (though IMHO this should also cause a bump in the binary version, as it changes the overall compatibility) i.e. option B, but actually we can't do that to the main API since preserving Gitea compatibility is the goal. However, it would be a good idea for a Forgejo-specific API. > them maliciously taking over that endpoint That seems unlikely (I hope). > where do we start... I'd tend to go with either v2 Same as @dachary. > [...] or v10 or similar. I'm against this as our first step into SemVer compliance would be non-compliant. 😅 > we can put [our API] into a seperate package You mean creating a binary that only contains `/api/vX` and another that contains both `/api/vX` and `/api/forgejo/vX` ?

gapodo commented 2023年01月04日 00:09:57 +01:00

i.e. option B, but actually we can't do that to the main API since preserving Gitea compatibility is the goal.

Mostly, though I am at this point assuming we won't keep much more than 1 API major version, as maintaining API versions is a burden as well... so new API likely means drop old -> pretty much all API changes are also "binary" breaking

I'm against this as our first step into SemVer compliance would be non-compliant. 😅

That is debateable (there is no requirement for not increasing the major version just statements on when it MUST be and that it MUST be increased numerically, though numerically doesn't mean by 1 just positive and number...) but if you want, I'll just push 9 incompatible changes...

The main reason for proposing v10 is that it's not likely to be similar to a Gitea version in the forseable future, so it avoids confusion... They may just make 1.19 2.0 as the new fangled CI feature is introduced (they are now backed by a company and potentially need the marketing bling of a new major version)

That seems unlikely (I hope).

I hope so as well, this was more of a "we should be fine, if we take this route" than a "this will happen". It was a reference to the reason for not using api/v2, so if they ever change to proper versions, we won't have a problem.

You mean creating a binary that only contains /api/vX and another that contains both /api/vX and /api/forgejo/vX ?

Not neccessarily as binary, but it would allow us to at least have a seperate go module, which would ease the integration burden and also allow us to "hard wire" our sdk support with our API by relying on a package or module that has our types and common functions centeralized...

> i.e. option B, but actually we can't do that to the main API since preserving Gitea compatibility is the goal. Mostly, though I am at this point assuming we won't keep much more than 1 API major version, as maintaining API versions is a burden as well... so new API likely means drop old -> pretty much all API changes are also "binary" breaking > I'm against this as our first step into SemVer compliance would be non-compliant. 😅 That is debateable (there is no requirement for not increasing the major version just statements on when it MUST be and that it MUST be increased numerically, though numerically doesn't mean by 1 just positive and number...) but if you want, I'll just push 9 incompatible changes... The main reason for proposing v10 is that it's not likely to be similar to a Gitea version in the forseable future, so it avoids confusion... They may just make 1.19 2.0 as the new fangled CI feature is introduced (they are now backed by a company and potentially need the marketing bling of a new major version) > That seems unlikely (I hope). I hope so as well, this was more of a "we should be fine, if we take this route" than a "this will happen". It was a reference to the reason for not using `api/v2`, so if they ever change to proper versions, we won't have a problem. > You mean creating a binary that only contains /api/vX and another that contains both /api/vX and /api/forgejo/vX ? Not neccessarily as binary, but it would allow us to at least have a seperate go module, which would ease the integration burden and also allow us to "hard wire" our sdk support with our API by relying on a package or module that has our types and common functions centeralized...

KaKi87 commented 2023年01月04日 01:12:14 +01:00

I am at this point assuming we won't keep much more than 1 API major version, as maintaining API versions is a burden as well

Well, at least one release must contain both APIs and mark the first as deprecated before a future one removes it.

That is debateable (there is no requirement for not increasing the major version just statements on when it MUST be and that it MUST be increased numerically, though numerically doesn't mean by 1 just positive and number...) but if you want, I'll just push 9 incompatible changes...

Unfortunately I can't argue with that. 😅

The main reason for proposing v10 is that it's not likely to be similar to a Gitea version in the forseable future, so it avoids confusion...

I'm not really convinced, that sounds like something that companies would do for communication purposes.

Statistically, there must be many other software in the same category that would have current version numbers near Gitea's and whatever Forgejo's would be.

> I am at this point assuming we won't keep much more than 1 API major version, as maintaining API versions is a burden as well Well, at least one release must contain both APIs and mark the first as deprecated before a future one removes it. > That is debateable (there is no requirement for not increasing the major version just statements on when it MUST be and that it MUST be increased numerically, though numerically doesn't mean by 1 just positive and number...) but if you want, I'll just push 9 incompatible changes... Unfortunately I can't argue with that. 😅 > The main reason for proposing v10 is that it's not likely to be similar to a Gitea version in the forseable future, so it avoids confusion... I'm not really convinced, that sounds like something that companies would do for communication purposes. Statistically, there must be many other software in the same category that would have current version numbers near Gitea's and whatever Forgejo's would be.

gapodo commented 2023年01月04日 01:36:10 +01:00

I'm not really convinced, that sounds like something that companies would do for communication purposes.

Agreed, but at the same time it's also the reason to do it (gain distance from potential marketing gags by gitea) if I could I'd also got to -100, it's "just a name"

Statistically, there must be many other software in the same category that would have current version numbers near Gitea's and whatever Forgejo's would be.

Yes there is a lot of software within the v1 range, though none of them are our direct upstream, where we also claim to be a drop-in replacement...

The thing I'd be trying to avoid, is to be on similar versions as gitea while the versions don't match at all from the "what's in it" point, it's really just to avoid confusion, like "why is my upgrade from gitea v2.0 to forgejo v2.0 not working...".

Being a drop-in replacement and advertising / communicating as such means that people are more likely to think our versions match, therefore we should either match, or be different enough in the number, so people will notice it by them self and not make "stupid" mistakes (just assume numbers match / accidentally not realize that they don't)...

> I'm not really convinced, that sounds like something that companies would do for communication purposes. Agreed, but at the same time it's also the reason to do it (gain distance from potential marketing gags by gitea) if I could I'd also got to -100, it's "just a name" > Statistically, there must be many other software in the same category that would have current version numbers near Gitea's and whatever Forgejo's would be. Yes there is a lot of software within the v1 range, though none of them are our direct upstream, where we also claim to be a drop-in replacement... The thing I'd be trying to avoid, is to be on similar versions as gitea while the versions don't match at all from the "what's in it" point, it's really just to avoid confusion, like "why is my upgrade from gitea v2.0 to forgejo v2.0 not working...". Being a drop-in replacement and advertising / communicating as such means that people are more likely to think our versions match, therefore we should either match, or be different enough in the number, so people will notice it by them self and not make "stupid" mistakes (just assume numbers match / accidentally not realize that they don't)...

KaKi87 commented 2023年01月04日 04:32:01 +01:00

Well, there actually won't be any excuse for confusion since the Gitea-compatible version will be concatenated to the Forgejo version as build metadata.

Well, there actually won't be any excuse for confusion since the Gitea-compatible version will be concatenated to the Forgejo version as build metadata.

Ghost commented 2023年01月04日 07:29:54 +01:00

@KaKi87 would you be willing to work on implementing the change to maintain the additional REST API endpoint that would be semver compatible? It seems to be doable and incremental with reasonably low effort. It will however require stamina, patience, excellent test coverage and some convincing to explain to the ecosystem around Forgejo that switching to using it is in their best interest. And also that they can rely on the person maintaining it to stay consistent and up to date over time.

@KaKi87 would you be willing to work on implementing the change to maintain the additional REST API endpoint that would be semver compatible? It seems to be doable and incremental with reasonably low effort. It will however require stamina, patience, excellent test coverage and some convincing to explain to the ecosystem around Forgejo that switching to using it is in their best interest. And also that they can rely on the person maintaining it to stay consistent and up to date over time.

gapodo commented 2023年01月04日 14:48:39 +01:00

Well, there actually won't be any excuse for confusion since the Gitea-compatible version will be concatenated to the Forgejo version as build metadata.

The reason for me proposing it is, that adding the +gitea.vX.Y.Z to the version isn't feasible in all places (think docker images, where length is limited and some characters are prohibited), but generally speaking you are right.

[...] and some convincing to explain to the ecosystem around Forgejo that switching to using it is in their best interest. And also that they can rely on the person maintaining it to stay consistent and up to date over time.

As long as we keep the API from upstream, people not willing to switch / depending on libraries not supporting it should be fine, so we have a smooth migration path.

---

Also having our own well versioned API could be a good startingpoint for future UI development, as we could then implement everything needed by the UI in the well versioned API, allowing for abstraction, also alternative UIs and 1st class citizenship for API tooling (currently the UI relies on a non stable API, which leads to issues when trying to replicate UI features via API)

> Well, there actually won't be any excuse for confusion since the Gitea-compatible version will be concatenated to the Forgejo version as build metadata. The reason for me proposing it is, that adding the `+gitea.vX.Y.Z` to the version isn't feasible in all places (think docker images, where length is limited and some characters are prohibited), but generally speaking you are right. > [...] and some convincing to explain to the ecosystem around Forgejo that switching to using it is in their best interest. And also that they can rely on the person maintaining it to stay consistent and up to date over time. As long as we keep the API from upstream, people not willing to switch / depending on libraries not supporting it should be fine, so we have a smooth migration path. ----- Also having our own well versioned API could be a good startingpoint for future UI development, as we could then implement everything needed by the UI in the well versioned API, allowing for abstraction, also alternative UIs and 1st class citizenship for API tooling (currently the UI relies on a non stable API, which leads to issues when trying to replicate UI features via API)

KaKi87 commented 2023年01月04日 16:31:21 +01:00

would you be willing to work on implementing the change to maintain the additional REST API endpoint that would be semver compatible?

No, sorry, I'm a JavaScript person 😅

> would you be willing to work on implementing the change to maintain the additional REST API endpoint that would be semver compatible? No, sorry, I'm a JavaScript person 😅

Ghost commented 2023年01月04日 16:42:17 +01:00

There is a fair amount of javascript in Forgejo but... it's not something that's consumed as an API I'm afraid :-)

In order for this to move forward the blocker is therefore to find someone willing to do the legwork. Not a huge undertaking, but not something you can finish within a week-end either. I'll keep an eye out. Maybe discussing this in the next monthly meeting would help attract good will?

There is a fair amount of javascript in Forgejo but... it's not something that's consumed as an API I'm afraid :-) In order for this to move forward the blocker is therefore to find someone willing to do the legwork. Not a huge undertaking, but not something you can finish within a week-end either. I'll keep an eye out. Maybe discussing this in the next monthly meeting would help attract good will?

KaKi87 commented 2023年01月04日 23:12:56 +01:00

Well, even if that API is not built by the next release, it still can be switched to SemVer, right ?

Well, even if that API is not built by the next release, it still can be switched to SemVer, right ?

Ghost commented 2023年01月05日 10:23:37 +01:00

How do you suggest Forgejo switch to SemVer so that tea and all the ecosystem of tools that rely on the previous version scheme keep working instead of becoming incompatible?

How do you suggest Forgejo switch to SemVer so that `tea` and all the ecosystem of tools that rely on the previous version scheme keep working instead of becoming incompatible?

KaKi87 commented 2023年01月05日 17:09:34 +01:00

Because the existing API will continue to return the Gitea-compatible version.

e.g. if the next Gitea version would be 1.19.0, then :

• the next Forgejo version would be 2.0.0+gitea-1.19.0 ;
• the existing version endpoint would output 1.19.0 ;
• the new version endpoint (if exists) would output 2.0.0.

Because the existing API will continue to return the Gitea-compatible version. e.g. if the next Gitea version would be `1.19.0`, then : - the next Forgejo version would be `2.0.0+gitea-1.19.0` ; - the existing version endpoint would output `1.19.0` ; - the new version endpoint (if exists) would output `2.0.0`.

gapodo commented 2023年01月05日 17:35:42 +01:00

• the existing version endpoint would output 1.19.0 ;

That would already need some major work IIRC, as that value is taken from the build..., so we'd need to at least modify the Makefile which is one of the more complex and fragile things within the system.

> - the existing version endpoint would output `1.19.0` ; That would already need some major work IIRC, as that value is taken from the build..., so we'd need to at least modify the `Makefile` which is one of the more complex and fragile things within the system.

KaKi87 commented 2023年01月05日 20:55:43 +01:00

Well, in that case, until stuff gets decorrelated, not only SemVer is unusable, but you can't even increment differently than Gitea (e.g. release 1.18.1 between 1.18.0 and 1.19.0) since third-party clients may not handle those properly.

Well, in that case, until stuff gets decorrelated, not only SemVer is unusable, but you can't even increment differently than Gitea (e.g. release `1.18.1` between `1.18.0` and `1.19.0`) since third-party clients may not handle those properly.

Ghost commented 2023年01月05日 21:07:57 +01:00

Right, so the goal is to find someone willing to do the work to make that happen. Again it's less complicated than I thought, thanks for explaining that quite clearly.

That's actually an interesting low energy and long term effort for which a contributor may feel motivated.

Forgejo is still very young and maybe this could be the first opportunity to send a very targeted call for contribution. @KaKi87 would you be interested in doing that? This issue has all the information a potential contributor would need to know what it entails and decide to go for it.

Right, so the goal is to find someone willing to do the work to make that happen. Again it's less complicated than I thought, thanks for explaining that quite clearly. That's actually an interesting low energy and long term effort for which a contributor may feel motivated. Forgejo is still very young and maybe this could be the first opportunity to send a very targeted call for contribution. @KaKi87 would you be interested in doing that? This issue has all the information a potential contributor would need to know what it entails and decide to go for it.

KaKi87 commented 2023年01月06日 00:28:08 +01:00

it's less complicated than I thought

@gapodo says otherwise 🤔

would you be interested in doing that?

I know nothing about compiled apps, makefiles, CI, Go, Gitea and Forgejo.

My programming capabilities are limited to interpreted, weakly and implicitly typed languages.

If I was going to work on this, I would be asking for assistance on Matrix all the time so it would be basically other people doing stuff.

> it's less complicated than I thought @gapodo says otherwise 🤔 > would you be interested in doing that? I know nothing about compiled apps, makefiles, CI, Go, Gitea and Forgejo. My programming capabilities are limited to interpreted, weakly and implicitly typed languages. If I was going to work on this, I would be asking for assistance on Matrix all the time so it would be basically other people doing stuff.

Ghost commented 2023年01月06日 00:55:30 +01:00

would you be interested in doing that?

I know nothing about compiled apps, makefiles, CI, Go, Gitea and Forgejo.

I did not mean doing it yourself, you were quite clear that it requires skills you don't have and I can appreciate that. Nobody has all the skills in the world :-)

I meant: would you be interested in launching and managing a call for contribution to do that task?

> > > would you be interested in doing that? > > I know nothing about compiled apps, makefiles, CI, Go, Gitea and Forgejo. I did not mean doing it yourself, you were quite clear that it requires skills you don't have and I can appreciate that. Nobody has all the skills in the world :-) I meant: would you be interested in launching and managing a call for contribution to do that task?

KaKi87 commented 2023年01月06日 01:56:54 +01:00

Oh, what would that entail ?

Oh, what would that entail ?

Ghost commented 2023年01月06日 09:36:10 +01:00

This is what would appeal to me as a contributor.

• An issue at https://codeberg.org/forgejo/forgejo/issues named "[SemVer] decoupling REST API version from release versions"
• The issue explains in detail (the description you wrote above is a great example) what needs to be done, a workplan of some kind.
• A blog post is published to draw attention to why and how SemVer should be adopted by Forgejo
• Toots are sent and discussions happen on the strategy and implementation for Forgejo to move to SemVer

This would be the first example of how Forgejo approaches a feature for which there is a need for an effort that spans over a long period of time. It would also be a fine example of how someone can effectively contribute to Forgejo even when they do not have the required technical skills to solve a particular problem.

In a nutshell you would spearhead a SemVer team and create the conditions for people to join.

Does that make sense?

This is what would appeal to me as a contributor. * An issue at https://codeberg.org/forgejo/forgejo/issues named "[SemVer] decoupling REST API version from release versions" * The issue explains in detail (the description you wrote above is a great example) what needs to be done, a workplan of some kind. * A blog post is published to draw attention to why and how SemVer should be adopted by Forgejo * Toots are sent and discussions happen on the strategy and implementation for Forgejo to move to SemVer This would be the first example of how Forgejo approaches a feature for which there is a need for an effort that spans over a long period of time. It would also be a fine example of how someone can effectively contribute to Forgejo even when they do not have the required technical skills to solve a particular problem. In a nutshell you would spearhead a SemVer team and create the conditions for people to join. Does that make sense?

KaKi87 commented 2023年01月06日 16:06:50 +01:00

An issue at https://codeberg.org/forgejo/forgejo/issues named "[SemVer] decoupling REST API version from release versions"
The issue explains in detail (the description you wrote above is a great example) what needs to be done, a workplan of some kind.

Will do !

A blog post is published to draw attention to why and how SemVer should be adopted by Forgejo

Should I make a PR at forgejo/website/data/blog ?

Toots are sent and discussions happen on the strategy and implementation for Forgejo to move to SemVer

Where should I submit this ?

It would also be a fine example of how someone can effectively contribute to Forgejo even when they do not have the required technical skills to solve a particular problem.

I'm interested.

> An issue at https://codeberg.org/forgejo/forgejo/issues named "[SemVer] decoupling REST API version from release versions" The issue explains in detail (the description you wrote above is a great example) what needs to be done, a workplan of some kind. Will do ! > A blog post is published to draw attention to why and how SemVer should be adopted by Forgejo Should I make a PR at [forgejo/website/data/blog](https://codeberg.org/forgejo/website/src/branch/main/data/blog) ? > Toots are sent and discussions happen on the strategy and implementation for Forgejo to move to SemVer Where should I submit this ? > It would also be a fine example of how someone can effectively contribute to Forgejo even when they do not have the required technical skills to solve a particular problem. I'm interested.

Ghost commented 2023年01月06日 17:24:17 +01:00

Should I make a PR at forgejo/website/data/blog ?

Yes, that's what I had in mind.

Toots are sent and discussions happen on the strategy and implementation for Forgejo to move to SemVer

Where should I submit this ?

That has never been done, you'd be the first. The other toots were part of the launch discussion. To keep things simple and since the toots are in support of the issue you'll create in https://codeberg.org/forgejo/forgejo, maybe these toots can be drafted and tracked in a https://codeberg.org/forgejo/forgejo issue that is linked (dependency?) of the main issue? It's a little unusual so maybe there are better ways to achieve this.

> Should I make a PR at forgejo/website/data/blog ? Yes, that's what I had in mind. >> Toots are sent and discussions happen on the strategy and implementation for Forgejo to move to SemVer > > Where should I submit this ? That has never been done, you'd be the first. The other toots were part of the launch discussion. To keep things simple and since the toots are in support of the issue you'll create in https://codeberg.org/forgejo/forgejo, maybe these toots can be drafted and tracked in a https://codeberg.org/forgejo/forgejo issue that is linked (dependency?) of the main issue? It's a little unusual so maybe there are better ways to achieve this.

Ghost commented 2023年01月06日 22:14:01 +01:00

@KaKi87 I think you have the required permissions to create the forgejo/SemVer issue label. Let me know if you don't.

@KaKi87 I think you have the required permissions to create the `forgejo/SemVer` issue label. Let me know if you don't.

KaKi87 commented 2023年01月08日 23:48:34 +01:00

Here's one more reason for SemVer adoption xD

Here's one more reason for SemVer adoption xD

Ghost commented 2023年01月09日 00:01:21 +01:00

Well, in this particular case it is not checking the version where it should: 1.18.0 is not a Forgejo version.

Well, in this particular case it is not checking the version where it should: 1.18.0 is not a Forgejo version.

KaKi87 commented 2023年01月09日 00:25:08 +01:00

For curious people, here's a table that converts Gitea's version increments into SemVer-compliant ones by parsing changelogs.

.--------------------------------------------------------------------------------------.
| ID | Actual version | Expected version | Actual increment | Expected increment |
|----------|----------------|------------------|------------------|--------------------|
| 4688573 | v0.9.99 | N/A | N/A | N/A |
| 5003661 | v1.0.0 | (same) | major | (same) |
| 5077231 | v1.0.1 | (same) | patch | (same) |
| 5522488 | v1.0.2 | (same) | patch | (same) |
| 5694462 | v1.1.0 | v2.0.0 | minor | major |
| 6281705 | v1.1.1 | v2.0.1 | patch | (same) |
| 6678811 | v1.1.2 | v2.0.2 | patch | (same) |
| 7299565 | v1.1.3 | v2.0.3 | patch | (same) |
| 7631798 | v1.1.4 | v2.0.4 | patch | (same) |
| 8090916 | v1.2.0 | v3.0.0 | minor | major |
| 8134999 | v1.2.1 | v3.0.1 | patch | (same) |
| 8279426 | v1.2.2 | v3.0.2 | patch | (same) |
| 8375251 | v1.2.3 | v3.0.3 | patch | (same) |
| 8705767 | v1.3.0 | v4.0.0 | minor | major |
| 8839711 | v1.3.1 | v4.0.1 | patch | (same) |
| 8902446 | v1.3.2 | v4.0.2 | patch | (same) |
| 9732643 | v1.3.3 | v4.0.3 | patch | (same) |
| 10247450 | v1.4.0 | v5.0.0 | minor | major |
| 10826804 | v1.4.1 | v6.0.0 | patch | major |
| 11369331 | v1.4.2 | N/A | N/A | N/A |
| 11663900 | v1.4.3 | v6.0.1 | patch | (same) |
| 12353987 | v1.5.0 | v6.1.0 | minor | (same) |
| 12695564 | v1.5.1 | v6.2.0 | patch | minor |
| 13331532 | v1.5.2 | v6.2.1 | patch | (same) |
| 13769792 | v1.5.3 | v6.2.2 | patch | (same) |
| 14150173 | v1.6.0 | v7.0.0 | minor | major |
| 14429075 | v1.6.1 | v7.0.1 | patch | (same) |
| 14662654 | v1.6.2 | v7.0.2 | patch | (same) |
| 14811092 | v1.6.3 | v7.0.3 | patch | (same) |
| 14997510 | v1.6.4 | v7.0.4 | patch | (same) |
| 15120433 | v1.7.0 | v8.0.0 | minor | major |
| 15297571 | v1.7.1 | v8.0.1 | patch | (same) |
| 15579675 | v1.7.2 | v8.0.2 | patch | (same) |
| 15817548 | v1.7.3 | v8.0.3 | patch | (same) |
| 16076510 | v1.7.4 | v8.0.4 | patch | (same) |
| 16393296 | v1.7.5 | v8.0.5 | patch | (same) |
| 16739869 | v1.7.6 | v8.0.6 | patch | (same) |
| 16883944 | v1.8.0 | v9.0.0 | minor | major |
| 17227181 | v1.8.1 | v9.0.1 | patch | (same) |
| 17666626 | v1.8.2 | v9.0.2 | patch | (same) |
| 18043861 | v1.8.3 | v9.0.3 | patch | (same) |
| 18987478 | v1.9.0 | v10.0.0 | minor | major |
| 19291645 | v1.9.1 | v11.0.0 | patch | major |
| 19473910 | v1.9.2 | v11.1.0 | patch | minor |
| 19829215 | v1.9.3 | v11.2.0 | patch | minor |
| 20558933 | v1.9.4 | v11.2.1 | patch | (same) |
| 21103400 | v1.9.5 | v12.0.0 | patch | major |
| 21457879 | v1.9.6 | v12.0.1 | patch | (same) |
| 21463923 | v1.10.0 | v13.0.0 | minor | major |
| 22007914 | v1.10.1 | v13.0.1 | patch | (same) |
| 22551718 | v1.10.2 | v13.0.2 | patch | (same) |
| 22941813 | v1.10.3 | v13.0.3 | patch | (same) |
| 23531602 | v1.11.0 | v14.0.0 | minor | major |
| 23718400 | v1.10.4 | v14.1.0 | minor | (same) |
| 23719109 | v1.11.1 | v14.1.1 | minor | patch |
| 24299308 | v1.11.2 | v15.0.0 | patch | major |
| 24407375 | v1.10.6 | N/A | N/A | N/A |
| 24407684 | v1.11.3 | v15.0.1 | minor | patch |
| 25102823 | v1.11.4 | v15.0.2 | patch | (same) |
| 26346091 | v1.11.5 | v15.1.0 | patch | minor |
| 27066107 | v1.11.6 | v15.1.1 | patch | (same) |
| 27694600 | v1.11.7 | v15.1.2 | patch | (same) |
| 27696259 | v1.12.0 | v16.0.0 | minor | major |
| 27766905 | v1.11.8 | v16.0.1 | minor | patch |
| 27767536 | v1.12.1 | v16.1.0 | minor | (same) |
| 28470108 | v1.12.2 | v16.2.0 | patch | minor |
| 29048925 | v1.12.3 | v16.2.1 | patch | (same) |
| 30691834 | v1.12.4 | v16.3.0 | patch | minor |
| 32066772 | v1.12.5 | v16.4.0 | patch | minor |
| 34005671 | v1.12.6 | v16.4.1 | patch | (same) |
| 34671886 | v1.13.0 | v17.0.0 | minor | major |
| 35781435 | v1.13.1 | v17.1.0 | patch | minor |
| 37206774 | v1.13.2 | v17.2.0 | patch | minor |
| 39281209 | v1.13.3 | v17.2.1 | patch | (same) |
| 39398805 | v1.13.4 | v17.2.2 | patch | (same) |
| 40122848 | v1.13.5 | v17.3.0 | patch | minor |
| 40251628 | v1.13.6 | v17.4.0 | patch | minor |
| 41072637 | v1.13.7 | v17.5.0 | patch | minor |
| 41235429 | v1.14.0 | v18.0.0 | minor | major |
| 41518988 | v1.14.1 | v18.1.0 | patch | minor |
| 42662313 | v1.14.2 | v18.2.0 | patch | minor |
| 44877729 | v1.14.3 | v18.3.0 | patch | minor |
| 45773551 | v1.14.4 | v18.3.1 | patch | (same) |
| 46302933 | v1.14.5 | v18.4.0 | patch | minor |
| 47404635 | v1.14.6 | v18.4.1 | patch | (same) |
| 48230908 | v1.15.0 | v19.0.0 | minor | major |
| 48912705 | v1.14.7 | v19.0.1 | minor | patch |
| 48918396 | v1.15.1 | v19.0.2 | minor | patch |
| 48960628 | v1.15.2 | v19.0.3 | patch | (same) |
| 50005764 | v1.15.3 | v19.1.0 | patch | minor |
| 51055426 | v1.15.4 | v19.2.0 | patch | minor |
| 51836480 | v1.15.5 | v19.2.1 | patch | (same) |
| 52210850 | v1.15.6 | v19.2.2 | patch | (same) |
| 54529608 | v1.15.7 | v19.3.0 | patch | minor |
| 55717945 | v1.15.8 | v19.3.1 | patch | (same) |
| 56200040 | v1.15.9 | v19.4.0 | patch | minor |
| 57146752 | v1.15.10 | v19.4.1 | patch | (same) |
| 58285575 | v1.15.11 | v19.4.2 | patch | (same) |
| 58287520 | v1.16.0 | v20.0.0 | minor | major |
| 58812507 | v1.16.1 | v20.1.0 | patch | minor |
| 60410349 | v1.16.2 | v20.2.0 | patch | minor |
| 60859500 | v1.16.3 | v20.3.0 | patch | minor |
| 61816764 | v1.16.4 | v20.4.0 | patch | minor |
| 62637490 | v1.16.5 | v21.0.0 | patch | major |
| 64908453 | v1.16.6 | v21.1.0 | patch | minor |
| 65777771 | v1.16.7 | v21.1.1 | patch | (same) |
| 67001059 | v1.16.8 | v21.2.0 | patch | minor |
| 71830683 | v1.16.9 | v21.2.1 | patch | (same) |
| 73258309 | v1.17.0 | v22.0.0 | minor | major |
| 74773471 | v1.17.1 | v22.1.0 | patch | minor |
| 76429310 | v1.17.2 | v22.2.0 | patch | minor |
| 79989366 | v1.17.3 | v22.3.0 | patch | minor |
| 86867620 | v1.17.4 | v22.4.0 | patch | minor |
| 87548231 | v1.18.0 | v23.0.0 | minor | major |
'--------------------------------------------------------------------------------------'

For curious people, here's a table that converts Gitea's version increments into SemVer-compliant ones by parsing changelogs. ``` .--------------------------------------------------------------------------------------. | ID | Actual version | Expected version | Actual increment | Expected increment | |----------|----------------|------------------|------------------|--------------------| | 4688573 | v0.9.99 | N/A | N/A | N/A | | 5003661 | v1.0.0 | (same) | major | (same) | | 5077231 | v1.0.1 | (same) | patch | (same) | | 5522488 | v1.0.2 | (same) | patch | (same) | | 5694462 | v1.1.0 | v2.0.0 | minor | major | | 6281705 | v1.1.1 | v2.0.1 | patch | (same) | | 6678811 | v1.1.2 | v2.0.2 | patch | (same) | | 7299565 | v1.1.3 | v2.0.3 | patch | (same) | | 7631798 | v1.1.4 | v2.0.4 | patch | (same) | | 8090916 | v1.2.0 | v3.0.0 | minor | major | | 8134999 | v1.2.1 | v3.0.1 | patch | (same) | | 8279426 | v1.2.2 | v3.0.2 | patch | (same) | | 8375251 | v1.2.3 | v3.0.3 | patch | (same) | | 8705767 | v1.3.0 | v4.0.0 | minor | major | | 8839711 | v1.3.1 | v4.0.1 | patch | (same) | | 8902446 | v1.3.2 | v4.0.2 | patch | (same) | | 9732643 | v1.3.3 | v4.0.3 | patch | (same) | | 10247450 | v1.4.0 | v5.0.0 | minor | major | | 10826804 | v1.4.1 | v6.0.0 | patch | major | | 11369331 | v1.4.2 | N/A | N/A | N/A | | 11663900 | v1.4.3 | v6.0.1 | patch | (same) | | 12353987 | v1.5.0 | v6.1.0 | minor | (same) | | 12695564 | v1.5.1 | v6.2.0 | patch | minor | | 13331532 | v1.5.2 | v6.2.1 | patch | (same) | | 13769792 | v1.5.3 | v6.2.2 | patch | (same) | | 14150173 | v1.6.0 | v7.0.0 | minor | major | | 14429075 | v1.6.1 | v7.0.1 | patch | (same) | | 14662654 | v1.6.2 | v7.0.2 | patch | (same) | | 14811092 | v1.6.3 | v7.0.3 | patch | (same) | | 14997510 | v1.6.4 | v7.0.4 | patch | (same) | | 15120433 | v1.7.0 | v8.0.0 | minor | major | | 15297571 | v1.7.1 | v8.0.1 | patch | (same) | | 15579675 | v1.7.2 | v8.0.2 | patch | (same) | | 15817548 | v1.7.3 | v8.0.3 | patch | (same) | | 16076510 | v1.7.4 | v8.0.4 | patch | (same) | | 16393296 | v1.7.5 | v8.0.5 | patch | (same) | | 16739869 | v1.7.6 | v8.0.6 | patch | (same) | | 16883944 | v1.8.0 | v9.0.0 | minor | major | | 17227181 | v1.8.1 | v9.0.1 | patch | (same) | | 17666626 | v1.8.2 | v9.0.2 | patch | (same) | | 18043861 | v1.8.3 | v9.0.3 | patch | (same) | | 18987478 | v1.9.0 | v10.0.0 | minor | major | | 19291645 | v1.9.1 | v11.0.0 | patch | major | | 19473910 | v1.9.2 | v11.1.0 | patch | minor | | 19829215 | v1.9.3 | v11.2.0 | patch | minor | | 20558933 | v1.9.4 | v11.2.1 | patch | (same) | | 21103400 | v1.9.5 | v12.0.0 | patch | major | | 21457879 | v1.9.6 | v12.0.1 | patch | (same) | | 21463923 | v1.10.0 | v13.0.0 | minor | major | | 22007914 | v1.10.1 | v13.0.1 | patch | (same) | | 22551718 | v1.10.2 | v13.0.2 | patch | (same) | | 22941813 | v1.10.3 | v13.0.3 | patch | (same) | | 23531602 | v1.11.0 | v14.0.0 | minor | major | | 23718400 | v1.10.4 | v14.1.0 | minor | (same) | | 23719109 | v1.11.1 | v14.1.1 | minor | patch | | 24299308 | v1.11.2 | v15.0.0 | patch | major | | 24407375 | v1.10.6 | N/A | N/A | N/A | | 24407684 | v1.11.3 | v15.0.1 | minor | patch | | 25102823 | v1.11.4 | v15.0.2 | patch | (same) | | 26346091 | v1.11.5 | v15.1.0 | patch | minor | | 27066107 | v1.11.6 | v15.1.1 | patch | (same) | | 27694600 | v1.11.7 | v15.1.2 | patch | (same) | | 27696259 | v1.12.0 | v16.0.0 | minor | major | | 27766905 | v1.11.8 | v16.0.1 | minor | patch | | 27767536 | v1.12.1 | v16.1.0 | minor | (same) | | 28470108 | v1.12.2 | v16.2.0 | patch | minor | | 29048925 | v1.12.3 | v16.2.1 | patch | (same) | | 30691834 | v1.12.4 | v16.3.0 | patch | minor | | 32066772 | v1.12.5 | v16.4.0 | patch | minor | | 34005671 | v1.12.6 | v16.4.1 | patch | (same) | | 34671886 | v1.13.0 | v17.0.0 | minor | major | | 35781435 | v1.13.1 | v17.1.0 | patch | minor | | 37206774 | v1.13.2 | v17.2.0 | patch | minor | | 39281209 | v1.13.3 | v17.2.1 | patch | (same) | | 39398805 | v1.13.4 | v17.2.2 | patch | (same) | | 40122848 | v1.13.5 | v17.3.0 | patch | minor | | 40251628 | v1.13.6 | v17.4.0 | patch | minor | | 41072637 | v1.13.7 | v17.5.0 | patch | minor | | 41235429 | v1.14.0 | v18.0.0 | minor | major | | 41518988 | v1.14.1 | v18.1.0 | patch | minor | | 42662313 | v1.14.2 | v18.2.0 | patch | minor | | 44877729 | v1.14.3 | v18.3.0 | patch | minor | | 45773551 | v1.14.4 | v18.3.1 | patch | (same) | | 46302933 | v1.14.5 | v18.4.0 | patch | minor | | 47404635 | v1.14.6 | v18.4.1 | patch | (same) | | 48230908 | v1.15.0 | v19.0.0 | minor | major | | 48912705 | v1.14.7 | v19.0.1 | minor | patch | | 48918396 | v1.15.1 | v19.0.2 | minor | patch | | 48960628 | v1.15.2 | v19.0.3 | patch | (same) | | 50005764 | v1.15.3 | v19.1.0 | patch | minor | | 51055426 | v1.15.4 | v19.2.0 | patch | minor | | 51836480 | v1.15.5 | v19.2.1 | patch | (same) | | 52210850 | v1.15.6 | v19.2.2 | patch | (same) | | 54529608 | v1.15.7 | v19.3.0 | patch | minor | | 55717945 | v1.15.8 | v19.3.1 | patch | (same) | | 56200040 | v1.15.9 | v19.4.0 | patch | minor | | 57146752 | v1.15.10 | v19.4.1 | patch | (same) | | 58285575 | v1.15.11 | v19.4.2 | patch | (same) | | 58287520 | v1.16.0 | v20.0.0 | minor | major | | 58812507 | v1.16.1 | v20.1.0 | patch | minor | | 60410349 | v1.16.2 | v20.2.0 | patch | minor | | 60859500 | v1.16.3 | v20.3.0 | patch | minor | | 61816764 | v1.16.4 | v20.4.0 | patch | minor | | 62637490 | v1.16.5 | v21.0.0 | patch | major | | 64908453 | v1.16.6 | v21.1.0 | patch | minor | | 65777771 | v1.16.7 | v21.1.1 | patch | (same) | | 67001059 | v1.16.8 | v21.2.0 | patch | minor | | 71830683 | v1.16.9 | v21.2.1 | patch | (same) | | 73258309 | v1.17.0 | v22.0.0 | minor | major | | 74773471 | v1.17.1 | v22.1.0 | patch | minor | | 76429310 | v1.17.2 | v22.2.0 | patch | minor | | 79989366 | v1.17.3 | v22.3.0 | patch | minor | | 86867620 | v1.17.4 | v22.4.0 | patch | minor | | 87548231 | v1.18.0 | v23.0.0 | minor | major | '--------------------------------------------------------------------------------------' ```

Ghost commented 2023年01月13日 23:57:28 +01:00

Related to #242

Related to https://codeberg.org/forgejo/forgejo/pulls/242

KaKi87 commented 2023年02月28日 13:38:48 +01:00

Progress report

Task	Issue	PR	Release
Create semantic version & /api/forgejo/v1/version endpoint returning it	#212	#242	1.19.0-0
Name binaries after semantic version	#455	-	-
Redirect tag references to Gitea version	-	-	-
Name tag after semantic version	-	-	-

### Progress report | Task | Issue | PR | Release | | --- | --- | --- | --- | | Create semantic version & `/api/forgejo/v1/version` endpoint returning it | #212 | #242 | `1.19.0-0` | | Name binaries after semantic version | #455 | - | - | | Redirect tag references to Gitea version | - | - | - | | Name tag after semantic version | - | - | - |

earl-warren commented 2023年04月03日 18:02:54 +02:00

@KaKi87 it would be useful to have the progress report in the issue description, if that's not too much trouble.

@KaKi87 it would be useful to have the progress report in the issue description, if that's not too much trouble.

KaKi87 commented 2023年04月03日 18:04:54 +02:00

Done.

Done.

earl-warren commented 2023年09月09日 10:34:19 +02:00

A little progress with the introduction of tests based on semantic versions for upgrades. But nothing more otherwise.

A little progress with the introduction of tests based on semantic versions for upgrades. But nothing more otherwise.

earl-warren commented 2024年02月28日 12:06:53 +01:00

Final step of the switch to semantic versioning at #2459

Final step of the switch to semantic versioning at https://codeberg.org/forgejo/forgejo/pulls/2459