Skip to content

xdp: Switch to a new versioning scheme - #2042

Merged
swick merged 1 commit into
flatpak:mainfrom
swick:wip/new-versioning
Jul 31, 2026
Merged

xdp: Switch to a new versioning scheme#2042
swick merged 1 commit into
flatpak:mainfrom
swick:wip/new-versioning

Conversation

@swick

@swick swick commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

We currently have something which resembles semantic versioning, but the minor releases are stable when the number if even, and unstable when the number is odd.

This also means the first number is fixed at 1 because we never break backwards compatibility.

A lot of people get confused by the odd/even scheme. Distros like Fedora have been shipping unstable releases. Distros like Arch have not been testing any of the unstable releases. Systems like GNOME OS have started shipping xdp from git main in their nightly where we will notice when something went wrong immediately.

Releases are work. Doing them needs to have a benefit. It does not seem like there is any benefit for us to do the unstable releases.

Given that unstable releases are a waste of time and that the major version is fixed, this commit changes the project over to a scheme where...

  • all releases are stable releases
  • the version number is major.minor
  • minor versions get released to deal with security issues and bugs
  • only the latest major release is supported

The next release will be version 23.0 because we would have releases 1.23.0 in the old versioning scheme.

@tytan652

tytan652 commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Given that unstable releases are a waste of time and that the major version is fixed

Just for clarity or being addressed explicitly here, the new scheme will not have things alike to .dev, .alpha, .beta or .rc even when it's a version in development ?

@swick

swick commented Jun 24, 2026

Copy link
Copy Markdown
Collaborator Author

Correct. Testing can be done by building from main, just like GNOME OS does.

@swick

swick commented Jun 24, 2026

Copy link
Copy Markdown
Collaborator Author

@Sodivad

Sodivad commented Jun 24, 2026

Copy link
Copy Markdown
Collaborator

I agree the current scheme is just too confusing.

@AdrianVovk AdrianVovk left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been in favor of something like this since #1779. So, LGTM!

(Also, we should note that this PR supersedes #1779)

@GeorgesStavracas GeorgesStavracas left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No objections

@swick
swick force-pushed the wip/new-versioning branch from f3ed8ed to 92d8ea2 Compare July 31, 2026 19:14
We currently have something which resembles semantic versioning, but the
minor releases are stable when the number if even, and unstable when the
number is odd.

This also means the first number is fixed at 1 because we never break
backwards compatibility.

A lot of people get confused by the odd/even scheme. Distros like Fedora
have been shipping unstable releases. Distros like Arch have not been
testing any of the unstable releases. Systems like GNOME OS have started
shipping xdp from git main in their nightly where we will notice when
something went wrong immediately.

Releases are work. Doing them needs to have a benefit. It does not seem
like there is any benefit for us to do the unstable releases.

Given that unstable releases are a waste of time and that the major
version is fixed, this commit changes the project over to a scheme
where...

* all releases are stable releases
* the version number is major.minor
* minor versions get released to deal with security issues and bugs
* only the latest major release is supported

The next release will be version 23.0 because we would have releases
1.23.0 in the old versioning scheme.
@swick
swick force-pushed the wip/new-versioning branch from 92d8ea2 to be84a13 Compare July 31, 2026 20:22
@swick
swick enabled auto-merge July 31, 2026 20:24
@swick
swick added this pull request to the merge queue Jul 31, 2026
Merged via the queue into flatpak:main with commit 65e91ad Jul 31, 2026
7 checks passed
@swick
swick deleted the wip/new-versioning branch July 31, 2026 20:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants