Winter Patch Releases

Greg Troxel gdt at lexort.com
Tue Mar 4 11:49:58 PST 2025


Martin Davis <mtnclimb at gmail.com> writes:

> For more context, I was cleaning up the remnants of the old overlay
> engine.  It had already been substantially removed in
> https://github.com/libgeos/geos/pull/788.  There were a few bits left,
> which were used internally only by the buffer algorithm.  It seems pretty
> unlikely that any external code uses just those pieces of the old overlay
> engine.  In fact, the cleanup didn't delete the code, but just moved it
> into the buffer package.
>
> But I realize now that #788 was done before 3.13.0 was released, so it
> appeared a "major" release.  My bad.
>
> If it's a problem, it's easy to add the files back in.

If we think it's very unlikely any depending program would use the
withdraw headers, I don't see a need to fix.

Not sure what Paul means by "philosophy".   There are strong conventions
in packaging that

  Upstream releases either are API compatible with the previous (no
  interface changes = micro, additional but no withdrawn or changed APIs = minor)
  or have API breaks = major.

  Packaging systems within what is considered stable (varies, but e.g. a
  pkgsrc branch or a Debian numbered release) only update to micro or
  micro-or-minor, depending on the system.

  NEWS should highlight any API breaks or ABI breaks, so that people
  doing package updates get this right.

These properties more or less guarantee that (perhaps with rebuilding)
all other programs will continue to work with the updated version.

And thus, that in large part the point of micro releasse is that they
can be safely updated to, even in stable branches.  If that's not what
they are for, then I wonder where they should be used, and why we have
so many sort-of-stable release branches.  I would have thought that the
point of the older release branches was to be able to deliver security
fixes and bug fixes without API breaks.

I get it that in this case, the header withdrawal/move something that is
expected to result in 0 actual build failures, and that fixing them is
likely to be easy, so I've pushed the update.



More information about the geos-devel mailing list