XLibre
Switch to semantic versioning and make the next feature release a 25.1.0 #299
Replies: 5 comments 14 replies
-
|
@X11Libre/wranglers What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, with the next major (abi-breaking) release. Can't do this earlier, because it would break ABI (module pathes) |
Beta Was this translation helpful? Give feedback.
-
|
Could you please reread the above section "Adressing the Current Versioning Scheme"? There is already a detailed explanation. But maybe I should go into more detail here: Using the notation of Semantic Versioning, the current XLibre Versioning is:
You told me that the Alltogether: We can just declare to cut the last number as we are allowed to introduce breaking changes in major versions and be done. This is a chance and I would very much like to use it to switch to Semantic Versioning.
What module paths would be broken and how? |
Beta Was this translation helpful? Give feedback.
-
|
Right now, the two components of the major number ("25.0", "25.1", ...) are part of the per-ABI module subdirectory (named "xlibre-"" + major-version). if we're going to pure semver, then the major would only be "25", "26", ..., thus these subdirs named "xlibre-25", "xlibre-26", ... therefore we should do that switch with next abi-breaking major release, and directly call it "26" instead of "25.1". |
Beta Was this translation helpful? Give feedback.
-
Yes.
NO. I had a look at the module loader code and created a simple patch: diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
index 1fd1f15df..0418ed56b 100644
--- a/hw/xfree86/loader/loadmod.c
+++ b/hw/xfree86/loader/loadmod.c
@@ -180,6 +180,12 @@ static const char *stdSubdirs[] = {
XORG_MODULE_ABI_TAG "/input/",
XORG_MODULE_ABI_TAG "/drivers/",
XORG_MODULE_ABI_TAG "/extensions/",
+ // next try loading from legacy xlibre-25.0 ABI subdir
+ // TODO remove this in version 26
+ "xlibre-25.0/",
+ "xlibre-25.0/input/",
+ "xlibre-25.0/drivers/",
+ "xlibre-25.0/extensions/",
// now try loading from legacy / unversioned directories
"",
"input/",
diff --git a/hw/xfree86/meson.build b/hw/xfree86/meson.build
index 06baa2344..5b1e51dbd 100644
--- a/hw/xfree86/meson.build
+++ b/hw/xfree86/meson.build
@@ -1,4 +1,4 @@
-module_abi_tag = 'xlibre-25.0'
+module_abi_tag = 'xlibre-25'
module_abi_dir = join_paths(module_dir, module_abi_tag)
xorg_inc = include_directories(I compiled the package I restarted the Xserver. Running My mouse and keyboard just work™. |
Beta Was this translation helpful? Give feedback.
-
|
I have created xfree86: enable semantic versioning by callmetango · Pull Request #647 · X11Libre/xserver containing this patch. |
Beta Was this translation helpful? Give feedback.
-
With this example, if It looks like it would be unnecessary to release a |
Beta Was this translation helpful? Give feedback.
-
Which distros published packages for the |
Beta Was this translation helpful? Give feedback.
-
|
These distros: Are We XLibre Yet? · X11Libre/xserver Wiki |
Beta Was this translation helpful? Give feedback.
-
Unfortunately it is not only about the package database but also about the packages installed. Package management software would not downgrade these if not explicitly told so. As appealing as a version |
Beta Was this translation helpful? Give feedback.
-
If https://github.com/orgs/X11Libre/discussions/211 is representative of the userbase with different distros and WMs, they all are tinkerers that know how to interact with their systems. So I don't see it as a blocker. |
Beta Was this translation helpful? Give feedback.
-
|
The Liberated Screens · X11Libre · Discussion #211 is not really representative as I understand it. Quoting the introduction:
We encouraged the users to tinker, score a "First one on ...!" and show their skills. I think our "regular" user base is running XLibre on Artix Linux and OpenMandriva LX and some also on Arch Linux resp. the derivatives since there are precompiled and maintained packages available. The tinkerers are more likely using Arch something too, FreeBSD, Gentoo and some also NixOS and Slackware. And there are the ones which just bring it to some places we never expected like Bedrock Linux, DeLinuxCo etc. |
Beta Was this translation helpful? Give feedback.
-
|
Tracked in Use Semantic Versioning instead of 25.0.x.x · Issue #646 · X11Libre/xserver. |
Beta Was this translation helpful? Give feedback.
-
|
@metux @callmetango Then 25.1.0, ... 26.0.0, ... will proceed according to semantics versioning, with bugfixing balanced with adding new features. |
Beta Was this translation helpful? Give feedback.
-
|
To me: Yes! That is exactly my idea here. The title "Switch to semantic versioning and make the next release a 25.1.0" might have been a bit confusing. Changed it to be clearer. |
Beta Was this translation helpful? Give feedback.
-
|
Resolved by resolving Use Semantic Versioning instead of 25.0.x.x · Issue #646 · X11Libre/xserver. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the idea
We should switch to Semantic Versioning as very soon as possible and release the next version not as
25.0.1.0but25.1.0.It should be done because
At the moment the XLibre project is using a versioning scheme with
25.0.for the major version which is quite uncommon and has to be explained most of the time instead of just being used. On the "outside" this project is perceived to be "infantil" due to assuming that we are still far away from a stable out-of-beta 25.1.0 release - judging by the version number.Regarding the tagging of the driver versions there are also for example some issues open which cannot be resolved without prior communication and involving @metux. Not meant to be mean, but just unsure what the next version label was. Also for another example running
X -versionreturns version number25.0.0regardless of any last number increments like in25.0.0.7. Having a look at the Liberated Screens · X11Libre · Discussion #211 it is also obvious that this scheme is quite easy to confuse.In contrast, Semantic Verisioning is a very simple, but also very effective and very widely accepted versioning scheme. Quoting the summary section of the specification‘s website:
Given a version number MAJOR.MINOR.PATCH, increment the:
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
In addition there also are some rules for alpha and beta release versions which we could utilize to implictly communicate the scope and stability of our releases.
By switching to Semantic Versioning we can reduce the communication overhead quite a lot. Every packager out there will understand whether the version brings some incompatible API changes, new features or "just" some bug fixes.
Using it throughout the whole project for e.g. versioning milestones, the XLibre contributors and maintainers will also know what to expect. Assigning milestones to feature requests or bug reports will be simple and intuitve by just answering the question "Breaking change or new feature or bug fix?".
Adressing the Current Versioning Scheme
I don‘t know why a four number versioning scheme was chosen, but I know that one has to read the
25.0.0.0as250.0.0. This is quite unusual and has to be explained to everybody as mentioned above. But we can do better in the next major = minor release of XLibre. Here is how:Following the four number versioning scheme, the next minor would be
25.0.1.0. Breaking out of it would require us to increment the „major“ number25.0to25.1. And bahm, there you have it! Release25.1.0. We just have to declare us breaking the version scheme, get rid of the fourth number and stick to Semantic Versioning for the future, fun and profit.AFAIK one of the very rare changes needed would be to adjust the modules path from
<prefix>/lib/xorg/modules/xlibre-25.0/to<prefix>/lib/xorg/modules/xlibre-25/. However, since25.1.0is a major version according to the old versioning scheme, which entails a change to the API, this would be acceptable and the drivers would have to be rebuilt either way to align to the new versioning scheme. If this was not an option, we could also patch the loader to look for modules in<prefix>/lib/xorg/modules/xlibre-25/as well as<prefix>/lib/xorg/modules/xlibre-25.0/and declare the latter one as legacy.What are the alternatives?
Keep the current versioning scheme and explaining it but what for?
Additional context
No response
Extra fields
Beta Was this translation helpful? Give feedback.
All reactions