25.1.0 Release planning

[metux]

Describe the task

Planning for 25.0.1 release -- additional features, but no ABI change.

Quick summary what's already done

New Features

• #19
  • kdrive-based, upstreamed from @stefan11111's fork
• enable dma-buf on NVIDIA
• #208
• udev support on FreeBSD

Support for Proprietary Nvidia Drivers

• #1330

Documentation Updates

• https://github.com/X11Libre/misc/issues/148
• #458
• improved Xi documentation d71ca037
• X11Libre/xserver#436
• X11Libre/xserver#301

Infrastructure Improvements

• CI: win32/mingw build
• CI: testing stages now up and running
• various WIN32/MINGW build fixes & added MINGW build to CI

Bug Fixes

• various bugfixes (also in 25.0.x)
• modesetting: fixed cursor size probing
• fbdev module fixes and improved probing

Support for Proprietary Nvidia Drivers

• #311
• #310
• #158

Code Cleanups

• dropped ancient (non-functional) DGA-1.0
• many, many code cleanups again (eg. reducing ifdef-zoo)
• added x_rpcbuf_t for easier RPC reply payload assembly -- now used in most places
• simplified huge part of the request handlers, eg. macros for common simple things
• incorporate and radically simplify (formerly external) Xtrans
• several fixes of code quality alerts
• various WIN32/MINGW build fixes
• compile-time asserts for reply struct size checking
• moved in-tree drivers to separate directories (video vs input), and moved meson logic there
• several CI improvements, eg. garbage collection on old build jobs
• inlined many SProc*() functions, simplifying request parsing
• cleaned lots of int-signess issues
• simplified lots of Xinerama-related code pathes
• simplified screen interation by lambda-esque macros
• simplified Xkb code flow
• move more extensions to use screen hooks instead of wrapping screen procs directly
• various code formatting cleanups and using C99 style declarations
• simplifications ins reply/event write paths

Organizational Tasks

• https://github.com/X11Libre/xserver/issues/646

Blockers and Trackers

• The count of bugs in https://github.com/orgs/X11Libre/projects/2 should be almost zero
• https://github.com/X11Libre/misc/issues/371
  • Please track all driver-spefic issues related to release 25.1.0 with this issue!

Planned or WIP

• more xtrans and os layer code cleanups
• finish transition to rpcbuf
• more Xinerama cleanups
• ...

[callmetango]

I think it was best when we use this issue here for a rough overview of the tasks and utilize the 25.0.1 (upcoming minor - no ABI breaks) · Milestone #3 · X11Libre/xserver to tag any issue and pull request to get a clear picture of what's in the package.

[metux]

I think it was best when we use this issue here for a rough overview of the tasks and utilize the 25.0.1 (upcoming minor - no ABI breaks) · Milestone #3 · X11Libre/xserver to tag any issue and pull request to get a clear picture of what's in the package.

that's gonna be a looong list, since we've got so many small PRs.

[metux]

Updated the list of things done ... feel free to fix if I've forgotten something

@X11Libre/reviewers @X11Libre/wranglers

[metux]

If there aren't any blockers anymore, I'd like to make the release soon. @X11Libre/reviewers @X11Libre/wranglers

[cepelinas9000]

Don't forget to chose logo: https://github.com/X11Libre/xserver/issues/112

[stefan11111]

Planned or WIP

* finish transition to rpcbuf

What is left to do for this one?

[metux]

Planned or WIP

* finish transition to rpcbuf

What is left to do for this one?

Haven't checked everything yet. But it's not a blocker for the release anyways.

[b-aaz]

Don't we already support udev on FreeBSD? I think we can also mention patches made for DFBSD too (Some still need review/approval in the drivers).

[callmetango]

that's gonna be a looong list, since we've got so many small PRs.

Well, I don't want to list every mini code cleanup here, but mark them with milestone 25.1.0 if their target is milestone 25.1.0.

Pretty shure they will be rendered in the changelog and the Github release notes, but they are a legit part of the upcomming release.

[callmetango]

Updated the list of things done ... feel free to fix if I've forgotten something

I'm working primarly on preparing release 25.1.0 from now on. Expect updates to this issue and a lot of the others. 😉

[callmetango]

If there aren't any blockers anymore, I'd like to make the release soon.

There are some organizational blockers like updating the website etc. I will create tickets and list them here soon.

[stefan11111]

@metux Is the move to rpcbuf completed?

What are the blockers for the release?

[metux]

@metux Is the move to rpcbuf completed?

I think so. Perhaps there might be some few more little things I've forgotten.

What are the blockers for the release?

@callmetango IIRC had a few things to do left.

Since it's now almost half a year after the last release, maybe we could do the release exactly 6M after the previous, so winter solstice.

[metux]

@callmetango are you okay with Dec 21 as release date ?

[callmetango]

@metux

are you okay with Dec 21 as release date ?

Yes, I think this is realistic.

[metux]

@metux

are you okay with Dec 21 as release date ?

Yes, I think this is realistic.

Great. Lets align few days before.

[callmetango]

IIRC had a few things to do left.

Yes, I'd like to do some "paperwork" like finishing the "How to build XLibre", "Switching to XLibre" etc. things and create proper release notes.

[fredvs]

Huh, and what about the XLIbre logo poll and [EDIT] the official site-name?

[artist4xlibre]

Pls check https://github.com/X11Libre/xserver/pull/1591#issuecomment-3633273525

[callmetango]

XLIbre logo poll

IMO this takes some time and we shouldn't hold the release for this. So my suggestion is to do it incrementally.

[fredvs]

IMO this takes some time and we shouldn't hold the release for this. So my suggestion is to do it incrementally.

Okay, but you can already get an idea of ​​the proposed logos. Take a look at this test poll; all the proposed logos are there, resized to 100x100 to make choosing easier. https://github.com/fredvs/test/issues/63

[stefan11111]

Release is blocked by https://github.com/X11Libre/xserver/issues/1505

If we don't fix this, autoconfigure is broken, users without an xorg.conf will be hit hard.

For now, there are 2 fixes to pick from, unless something else is submitted, https://github.com/X11Libre/xserver/pull/1564 and https://github.com/X11Libre/xserver/pull/1587

[metux]

Release is blocked by #1505

If we don't fix this, autoconfigure is broken, users without an xorg.conf will be hit hard.

For now, there are 2 fixes to pick from, unless something else is submitted, #1564 and #1587

already merged the first PR today.

[artist4xlibre]

There are some things that need to be taken care of before Dec 21:

• will all drivers, or a subset of the popular ones, get a new release as these will need to be rebuilt against 25.1
• will there be a freeze and test period before releasing 25.1
• will 25.0 still be maintained, if yes that implies a conflicts/provides problem for users and maintainers and for Artix and Arch Linux not considered feasible to package it
• will, how, all users and maintainers be informed adequately

[metux]

• will all drivers, or a subset of the popular ones, get a new release as these will need to be rebuilt against 25.1

The sources are always backwards compatible for older Xlibre releases (as long as we're maintaining them), so no new release required. Release cycles are (almost) independent of each other - you just might need to update some drivers when updating the xserver (if you haven't already).

ABIs should also be compatible within the 25.x lines (just some unused entry points gone away)

I'd recommending updating the drivers when new releases come.

• will there be a freeze and test period before releasing 25.1

As usual, the X.Y.0 is considered beta/testing. We'll yet have to see whether it needs some more bugfix releases to mature. Leaving the decision to the distros, who've usually got more practical field experience :)

• will 25.0 still be maintained,

At least as long as people actually taking care of it :) In general, release branches only receiving bug fixes, no new features, refactoring, etc. The expected change rate is very low.

• if yes that implies a conflicts/provides problem for users and maintainers and for Artix and Arch Linux not considered feasible to package it

It's entirely up to individual distros, which versions to ship. We're not going to dictate anything here.

[metux]

@callmetango did already have some time for preparing release notes ?

[alexislefebvre]

• will there be a freeze and test period before releasing 25.1

As usual, the X.Y.0 is considered beta/testing. We'll yet have to see whether it needs some more bugfix releases to mature. Leaving the decision to the distros, who've usually got more practical field experience :)

What does “As usual” mean? How packagers can learn this important information, now and in the future? Is it documented somewhere that X.Y.0 are not stable releases?

A proper beta version should be tagged 25.1.0-beta1, not 25.1.0.

This usage of semver for non-stable releases was described in https://github.com/orgs/X11Libre/discussions/299:

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.

Do future releases will follow SemVer guidelines?

[callmetango]

@metux

@callmetango did already have some time for preparing release notes ?

I'll take care of them in #1684, starting today.

[callmetango]

@alexislefebvre

What does “As usual” mean? How packagers can learn this important information, now and in the future? Is it documented somewhere that X.Y.0 are not stable releases?

We'll communicate XLibre Xserver version 25.1.0 as the first beta in the 25.1 series everywhere we can. This will include a post on X11Libre/packaging Announcements · Discussions · GitHub CC'ing all known maintainers.

A proper beta version should be tagged 25.1.0-beta1, not 25.1.0.

The Semantic Versioning 2.0.0 specification says:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.

The first beta could therefore be designated as 25.1.0-beta.1 , but one does not have to use the pre-release versioning scheme.

We like to keep things simple and start with 25.1.0, counting up to maybe 25.1.2 and call something like 25.1.3 the stable release.

[callmetango]

@metux

I think it would be good to soft freeze the current Xserver code and stabilize it and fix bugs etc until we release 25.1.0.

We should also create a release/25.1 branch. Maybe on December 21.

I'd also like to rename the maint-25.0 branch into release/25.0 since it really is what it's called by then, and release/… is a common naming scheme. This change would then be announced to the known maintainers, etc. I could more broadly argue in favor of this if need be. :wink:

It would also be good to release all changes to any drivers using the Semantic Versioning scheme as planned in Tracker: Switch all drivers to semantic versioning when releasing Xserver 25.1.0 · Issue #379 · X11Libre/misc from now on.