1.6.0 release planning

[bluetech]

The plan is basically: once @wismill says we should :) Let me know you think we're in a good state in regards to your PRs (note: I do intent to go over all of them soon), then I'll do the release.

[wismill]

Thank you for your trust! I would like to finish the following PR:

• Test: Use a xvfb wrapper for x11 test #348: Almost ready.
• Improve interactive tools #352: Almost ready.
• Structured log messages with unique identifiers #332: Framework done, but I would like to add more warnings in a follow-up PR. It would be nice to include most common warnings in the release.
• Fix numeric keysym parsing #357: I found some issues with numeric keysyms while working on the previous PR. This PR improves robustness. should be easy to include in 1.6.0.
• Octal escape allows \0..\777 #363: Fresh bug. I think we should fix it in 1.6.0.
• Add new warning for deprecated keysyms #356: quite fresh; would be very useful for xkeyboard-config.
• Modern rules #362 (previously: Add support for :all in rules #334): need deep review. Not actionable until X11 xkbcomp and xkeyboard-config catch up? I do not see it in 1.6.0.
• Support querying whether virtual modifiers are active (alternative with overlapping mods API) #353: need deep review and impact assessment. Contrary to 334, it would be directly actionable, so it would be awesome to include it in 1.6.0.

[whot]

Not actionable until X11 xkbcomp and xkeyboard-config catch up? I do not see it in 1.6.0.

fwiw, realistically this means unless you add it to xkbcomp, it'll never happen. xkbcomp has been effectively unmaintained (functionality-wise) for decades now. And then there's the whole happy inertia game of xkeyboard-config not being able to ship rules with new features until they're wildly enough supported, which will take imperial yonks or metric ages.

I'll be trying to work my way through the others as I find time this week.

[wismill]

fwiw, realistically this means unless you add it to xkbcomp, it'll never happen.

I am aware of this. It may happen if:

• The design of the :all feature is validated and merged in xkbcommon.
• I have the guaranty that my potential work of X11 xkbcomp will be revised this year and, if validated, a release will follow soon after. I am OK to wait a few months for a review, but I will not find the motivation if there is nobody supporting this improvement.

there's the whole happy inertia game of xkeyboard-config not being able to ship rules with new features until they're wildly enough supported

Backward compatibility is mandatory and motivates changes to xkbcomp. I would wait a few xkeyboard-config releases after the xkbcomp one before proposing making use of the new feature, with a big warning in the release notes. I believe that communication to the main distros and the excellent QA of some of them (see e.g. openSUSE) should make the transition possible.

The feature is worth the effort.

[whot]

I have the guaranty that my potential work of X11 xkbcomp will be revised this year and, if validated, a release will follow soon after.

be careful what you wish for, you may just become the maintainer of xkbcomp if you do that :)
but after a very quick skim of #334 I think this may be a lot more "involved". IIRC xkbcomp doesn't do anything with the rules files directly, you're looking at libxkbfile and possibly libxklavier, both of which are woefully unmaintained but still required in various components - like the X server. I don't know off-hand whether there are any other projects parsing the rules files that would need to be fixed. Anyway - this comes down to: fixing libxkbfile instead of xkbcomp might get you 90% of the way there (and means you'll become the maintainer of libxkbfile ;)

[wismill]

@bluetech @whot currently almost all the items in the 1.6.0 milestone have been processed. We are close to a release.

As you can see there are still a few PR pending. I wish #356 could make it for this release, but I think further delaying the release is maybe not a good idea. So I already planned some PR for the future 1.7.0 release.

Now, I would like to know how do you proceed with release:

• How do you update the NEWS file? I guess you use the git history, but do you use a tool?
• Is there any other step before cutting the release?
• How do you proceed with the release tag?
• What are the next steps? I guess:
  • making a Github release
  • making a tarball and upload it to the website
  • send the announcement in the wayland-dev mailing list

I would like to help to make the release.

[bluetech]

How do you update the NEWS file? I guess you use the git history, but do you use a tool?

I don't use a tool, I just go over the commits.

Is there any other step before cutting the release?

Here's how I do it, it's somewhat laborious.

• Write the NEWS, update the version in meson.build, tag the release with git tag -a xkbcommon-1.6.0 -m xkbcommon-1.6.0.
• Run meson dist
• Upload the tarball to the server (SSH)
• Upload the version docs to the server, change the current symlink to point to it
• Push the tag to the repo
• Send email announcement to wayland-devel (this includes the NEWS and the sha256sum from meson dist)
• Update https://github.com/xkbcommon/website with the release, commit & push to repo
• Update the index.html on the server
• Create github release

[wismill]

Thanks for clarifying the steps.

The Github pages job is working quite nice. I wonder when could we switch the entire website (see #326).

Once we have switched to Github page-base website, we could write a manual job that deploy the release. Then the workflow would be:

1. Write the NEWS file
2. Update the version in meson.build, tag the release and push.
3. Run the release job
4. Create a Github release (could it be done with the previous job?)
5. Send the email annoucement.

I changed a bit the order, that seems more practical to me.

[bluetech]

The Github pages job is working quite nice. I wonder when could we switch the entire website (see #326).

The two tasks here are:

• Keep the version-specific docs e.g. https://xkbcommon.org/doc/1.5.0/ working. Maybe we can do it just committing each release docs to the github pages branch?
• Keep the tarball links e.g. https://xkbcommon.org/download/libxkbcommon-1.5.0.tar.xz working. Maybe we can do it by back-creating old releases in github, attching the tarballs to these releases, and redirecting to that?

After that it's just a matter of changing the DNS I think.

Once we have switched to Github page-base website, we could write a manual job that deploy the release. Then the workflow would be [...]

This sounds good to me.

In the meantime, I can handle the 1.6.0, it's not a problem. I see you've added a couple more PRs to the 1.6.0 milestone so I'll wait for them. Let me know if you want to write the NEWS for this release, otherwise I'll write it and send a PR.

[bluetech]

1.6.0 is released!