Answering to several people in a row: @Eli
> If people were not compelled to track master, then this > engagement with the project might be reduced or pushed to releases > with a less interactive feedback (i.e. they won't be testing patches > or recent commits). From my own personal experience, GDAL has been > the only project worth tracking master and engaging in this way. > Other projects, I wait for the release and take a binary and am less > in a position to provide testing or meaningful feedback. Tracking > master and engaging with GDAL has been a rewarding experience for me > over the years. I'm not sure why having shorter cycles would increase or decrease potential candidates to tracking master. It seems to me to be more related to their own interest in the project, which should be somewhat independent from the length of the cycle. People highly interested in the project should still track it as closely as they are used to if they want the same level of quality, and people more remotely interested will probably just wait for their binary distribution channel to bring releases to them. Having shorter feature cycles can also help reduce developer frustration: when you start getting bug reports for a feature you added > 1 year ago (because most users understandably use a packaged version), you may have already forgotten lots of details. When I update the NEWS file before release, I'm sometimes surprised to have to qualify as new something that looks to me as having been developed years ago :-) @Greg > API withdrawals/breaks We try to avoid those when possible. But we have more frequently changes that have some backward compatibility challenges (generally a few per feature version), not always detected at build time. That can be things like: - a new value added to a C enumeration in the API. Requiring user code to deal with this new possibility - an option disappearing / being renamed for more generality - other changes of runtime behaviour. Like in this cycle, the OGR SQL "LIKE" operator becoming case insensitive. Those are documented in the MIGRATION_GUIDE.TXT file. Adressing those changes for code using GDAL is almost equally important as making sure that the code still builds. > You didn't discuss the LTS elephant in the room. Speaking from my experience, candidates like proprietary shops that could provide $$ to make that happen generally resync their GDAL build with a release or some state of master from time to time. And perhaps potentially pick a particular bugfix of interest occasionaly. Regarding LTS-labelled Linux distros, for the few on I've looked at, they don't seem to update to the latest patch release we provide for a given feature version, and are stuck to the one that existed at the time the .0 of the distro was frozen. Probably lack of man power, or too strict update policies that restrict maintainers to do cherry-picking (quite risky IMHO when done not with someone intimate with the code base) rather than rolling a new patch release. For a project vetted LTS, beyond having acceptance within GDAL devs and potential funding for it, one difficulty would be to choose which version to LTS. Or perhaps do like QGIS does, just say "eh, every one out of N feature versions is the LTS.". People also tend to disagree what a LTS is: for some it is something mostly frozen with minimal changes (security ones), for others something that can receive any non-breaking change (including things that could qualify as features), and a lot of in-between situations (for QGIS we discussed recently the possibility to have several phases: an initial one where changes are accepted liberaly, and a last one where only "critical" bug fixes can land) But, anyway, I've not heard yet converging demands for such a thing for GDAL. > [Regarding PROJ] Breaking changes every year is faster than depending > projects have coped. Yes, was annoying but needed to keep PROJ relevant for current and future geodetic challenges, after years of stagnation. Our geospatial projects are lively objects that cannot be compared to Unix base tools that are almost set in stone forever :-) Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
