lxml 6.1.2-1 - Undocumented Patch Tag

lxml published GitHub tag lxml-6.1.2-1 on 18 August 2026. The release is not marked as a prerelease, beta, or release candidate. The GitHub body is empty, so the fact that matters for XML and HTML jobs is the missing changelog, not a listed parser change.

The full release notes and downloads are on the GitHub release page.

Empty GitHub release body ¶

The maintainers shipped a tagged GitHub release with no text. The published record is a tag, a timestamp, and a prerelease flag set to false. There is no bug list, no libxml2 note, no wheel matrix, and no migration paragraph.

For a native Python binding that sits in HTML scrape workers and XML ingest jobs, that gap is operational. A pin bump without a changelog is a blind rebuild of the parse path. lxml.etree and lxml.html are the functions that turn bytes into trees. They also run XPath, XSLT, and HTML recovery. Those code paths fail in ways that look like bad source data: dropped namespaces, mangled encodings, entity expansion errors, or trees that never finish building.

An empty GitHub body does not mean the tree is unchanged. It means the release page is not a changelog. Do not infer a security fix, a packaging only rebuild, or an API freeze from silence. Infer nothing until the tag is compared to the previous 6.1.2 tag in the repo.

If notes appear later on the same GitHub release page, reread them before promoting the pin. Until then, treat this page as a pointer to a git tag.

lxml GitHub tags usually take the form lxml-6.1.2. This tag adds a trailing 1 after the version. That extra suffix is a common packaging revision pattern. Debian style source versions use it. Some projects reuse it for a second tag of the same upstream version. The GitHub page does not say which of those this is.

Do not treat the suffix as a noop. A second tag can be a retag of the same tree, a packaging metadata edit, a rebuilt native extension, or a silent source delta. All four look the same on an empty release page. Only a tag diff tells them apart.

The version core is still 6.1.2. The suffix is the part that needs a human check. If your lock file already pins 6.1.2, lxml-6.1.2-1 is not an automatic match. Resolve the tag to a commit, then compare that commit to the 6.1.2 tag you already trust.

Name collisions are the other risk. Build systems that strip the lxml- prefix and keep the rest will see 6.1.2-1. Systems that parse only dotted numbers may keep 6.1.2 and drop the suffix. Those two readings produce different pins. Confirm what your resolver stores before CI and production disagree.

Pin updates for this tag should start in git, not on the empty release page. Fetch the tag. Diff lxml-6.1.2 against lxml-6.1.2-1. If the diff is empty, the extra suffix is a retag and the parser behavior should match 6.1.2. If the diff is not empty, read every changed file before the pin moves.

After the diff, rerun the parse jobs that actually fail in production, not a hello world XML snippet.

  • Well formed XML with namespaces and mixed encodings
  • Broken HTML that depends on recovery parsing
  • XPath selections that assume a stable tree shape
  • XSLT transforms that the pipeline still ships
  • Large documents that used to complete without extra RSS growth

lxml wraps libxml2 and libxslt. An empty GitHub body will not mention a native library bump even if one landed in the tag. If you vendor wheels or compile the extension in CI, record the libxml2 and libxslt versions that the build linked. Compare those versions to the last known good 6.1.2 artifact. A parser pin that quietly changes the C library is still a parser change.

Do not skip the worker memory check. XML and HTML jobs fail first as RSS cliffs and as stuck workers, not as clean Python exceptions. Run one full size fixture through lxml.etree and one through lxml.html under the same ulimit and timeout you use in the cluster. If either path grows or stalls relative to 6.1.2, stop the rollout.

There is no published break list and no published migration step. The conservative move is to stay on the 6.1.2 pin you already tested until the tag diff is reviewed. If you must take lxml-6.1.2-1 on a deadline, isolate it to one worker image and keep a rollback tag ready.