<div dir="ltr"><div dir="ltr">Hi Jukka,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 8 May 2019 at 11:26, jratike80 <<a href="mailto:jukka.rahkonen@maanmittauslaitos.fi">jukka.rahkonen@maanmittauslaitos.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Even answered in a mail on Thu May 2 00:43:37 PDT 2019:<br>
<br>
"Well, I was about *releasing* the version, and don't intend to postpone it <br>
significantly, so no there won't be any surprise last-minute changes than<br>
the <br>
ones already documented in MIGRATION_GUIDE.TXT. After all, major version <br>
numbers are cheap, so if during the next dev cycle 3.1dev turns out to need <br>
API breaks, it will be 4.0 ..."<br></blockquote><div><br></div><div>Sure, numbers are cheap, but requiring users to stop & take the time to work through their codebases to check for and address a set of incompatible changes are the opposite — I don't think we want to be continually doing that.</div><div><br></div><div>For us at least, GDAL minor X.Y -> X.Y+1 upgrades are relatively straightforward: read the changelog, review things that look possibly problematic, reapply any patches we still need, build, run our test suites, QA, stage through to release.</div><div><br></div><div>I'm not majorly hung up on it, just something I wanted people to consider</div><div><br></div><div>Rob :)</div><div><br></div></div></div>