build: Change weekly versioning scheme of debian packages #2257

Merged

Jade merged 1 commit from spaetz/continuwuity:debversion into main

2026-10-12 09:13:24 +00:00

spaetz commented

2026-09-15 12:06:22 +00:00

Member

This pull request changes the weekly versioning naming scheme in order to improve the sort order.

Right now our weekly Debian versioning scheme is VERSION="$BASE_VERSION~git$DATE.$SHA-$CLEAN_COMPONENT".
This sorts weekly releases AFTER the BASE_VERSION, so when both stable
and unstable are enabled, we never get weekly versions installed.
https://wiki.debian.org/Versioning proposes {upcoming_version}~git{date}.{hash}-{revision} for nightly releases, which means we would have to know the release number of the upcoming version in advance. I don't think that is useful for us.

By switching from a tilde to a dash, our weekly versions are now sorted
above the stable base version and we will install the weekly versions
over the base version, which I believe is closer to what we intend.

Fixes: #2081

Pull request checklist:

If you aren't sure about some, feel free to ask for clarification in #dev:continuwuity.org. -->

This pull request targets the main branch, and the branch is named something other than
main.
I have written an appropriate pull request title and my description is clear.
I understand I am responsible for the contents of this pull request.
I have followed the contributing guidelines:
- My contribution follows the code style, if applicable.
- I ran pre-commit checks before opening/drafting this pull request.
- I have tested my contribution (or proof-read it for documentation-only changes)
  myself, if applicable. This includes ensuring code compiles.
- My commit messages follow the commit message format and are descriptive.

This pull request changes the weekly versioning naming scheme in order to improve the sort order. Right now our weekly Debian versioning scheme is VERSION="$BASE_VERSION~git$DATE.$SHA-$CLEAN_COMPONENT". This sorts weekly releases AFTER the BASE_VERSION, so when both stable and unstable are enabled, we never get weekly versions installed. https://wiki.debian.org/Versioning proposes {upcoming_version}~git{date}.{hash}-{revision} for nightly releases, which means we would have to know the release number of the upcoming version in advance. I don't think that is useful for us. By switching from a tilde to a dash, our weekly versions are now sorted above the stable base version and we will install the weekly versions over the base version, which I believe is closer to what we intend.   Fixes: #2081  **Pull request checklist:** If you aren't sure about some, feel free to ask for clarification in #dev:continuwuity.org. --> - [X] This pull request targets the `main` branch, and the branch is named something other than `main`. - [X] I have written an appropriate pull request title and my description is clear. - [X] I understand I am responsible for the contents of this pull request. - I have followed the [contributing guidelines][c1]: - [X] My contribution follows the [code style][c2], if applicable. - [X] I ran [pre-commit checks][c1pc] before opening/drafting this pull request. - [X] I have [tested my contribution][c1t] (or proof-read it for documentation-only changes) myself, if applicable. This includes ensuring code compiles. - [X] My commit messages follow the [commit message format][c1cm] and are descriptive. [c1]: https://forgejo.ellis.link/continuwuation/continuwuity/src/branch/main/CONTRIBUTING.md [c2]: https://forgejo.ellis.link/continuwuation/continuwuity/src/branch/main/docs/development/code_style.mdx [c1pc]: https://forgejo.ellis.link/continuwuation/continuwuity/src/branch/main/CONTRIBUTING.md#pre-commit-checks [c1t]: https://forgejo.ellis.link/continuwuation/continuwuity/src/branch/main/CONTRIBUTING.md#running-tests-locally [c1cm]: https://forgejo.ellis.link/continuwuation/continuwuity/src/branch/main/CONTRIBUTING.md#commit-messages

❤️ 1

forgejo-actions added the

Meta/CI

label

2026-09-15 12:06:26 +00:00

nex commented

2026-09-19 01:15:58 +00:00

Owner

https://wiki.debian.org/Versioning proposes {upcoming_version}~git{date}.{hash}-{revision} for nightly releases, which means we would have to know the release number of the upcoming version in advance. I don't think that is useful for us.

Technically, we can guess the "upcoming" version number. The first component of the version string is the last two digits of the current year, the second component is the current unpadded numeric month, and then the final component is just a serial value that increments for each release.
It's probably fair to assume that the final component can just be N+1, unless the numeric month or year values don't match the latest release, in which case it can just be Y.M.0. I'm pretty sure all of this can be calculated trivially in bash, but ofc if you don't want to do the work for semantic gains that's fine too

> https://wiki.debian.org/Versioning proposes {upcoming_version}~git{date}.{hash}-{revision} for nightly releases, which means we would have to know the release number of the upcoming version in advance. I don't think that is useful for us. Technically, we can guess the "upcoming" version number. The first component of the version string is the last two digits of the current year, the second component is the current unpadded numeric month, and then the final component is just a serial value that increments for each release. It's probably fair to assume that the final component can just be N+1, unless the numeric month or year values don't match the latest release, in which case it can just be Y.M.0. I'm pretty sure all of this can be calculated trivially in bash, but ofc if you don't want to do the work for semantic gains that's fine too

nex approved these changes

2026-09-19 01:17:06 +00:00

nex added the

Enhancement

Meta/Packaging

labels

2026-09-19 01:17:27 +00:00