Martin Davis <mtncl...@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.
