I would suggest that we should only commit to stable branches for the purpose of fixing a bug. No, we don't promise a stable API, so it may arise that we need/want to change the API in a micro release to accomodate a bugfix, though we still should try to avoid it (and generally have, I think.)
Changing the API in a stable branch because our aesthetics have changed, or because it might make it easier to backport a hypothetical bugfix, seems like a bad idea. If I were an external user of these typedefs ( https://github.com/search?q=geom%3A%3AGeometry%3A%3APtr+NOT+is%3Afork&type=code&p=1), or a packager of software that uses them, I would be upset that upgrading from 3.12.2 to 3.12.3 caused them to disappear. Dan On Thu, Jan 9, 2025 at 6:33 PM Martin Davis <mtncl...@gmail.com> wrote: > There seems to be agreement that purging pointer aliases is A Good Thing > To Do. > > Much of the usage in the test suite, with fewer occurrences present in the > main code base. So this makes it easier to clean up the main code base, > which is the priority. > > Not backporting the changes may make it harder in the future to port bug > fixes and improvements to older major versions. We don't promise ABI > stability for the C++ API, so I'm not sure whether this is a real concern? > > > On Thu, Jan 9, 2025 at 5:52 AM Daniel Baston <dbas...@gmail.com> wrote: > >> Hi Martin, >> >> I avoid the typedefs for the same reasons you listed, but they seem to be >> rarely used outside of unit tests (grep shows 97 lines with "Ptr" under >> "src" and 825 lines under "tests"). I'm not sure if a purge is the highest >> priority for improving the test suite, but am not opposed if others want to >> take that on. I would not be in favor of backporting this type of change, >> which would break the API in a minor release while offering no benefit to >> users. >> >> Dan >> >> On Wed, Jan 8, 2025 at 7:16 PM Martin Davis <mtncl...@gmail.com> wrote: >> >>> The GEOS codebase has several typedefs called GeometryPtr and GeomPtr. >>> They are aliases for a mixture of Geometry * and std::unique_Ptr<Geometry>. >>> I'm thinking it's a good thing to purge them from the codebase in favour of >>> explicit type signatures, because: >>> >>> - it's highly confusing that they can be aliases for different things >>> - it's complicated that they are defined in multiple places >>> - it can be hard to see what they represent >>> - they don't save much typing in the case of Geometry*, and using auto >>> can simplify other uses >>> >>> This was discussed a while back. The general feeling was that it's >>> better to use explicit types. Is this still the consensus? >>> >>> Some notes on the process: >>> - I expect this will be done in multiple passes, to fit work schedules. >>> Will start with the least intrusive changes >>> - when this is done, it needs to be backported so that subsequent >>> backports don't collide with unchanged code. >>> - If older versions use the aliases in dead code, it may not be removed, >>> just patched to ensure it still compiles (i.e. by leaving the typedefs in >>> place) >>> >>> >>> >>> >>>
