Alright, I have completed the JTS 1.18.2 release.
Artifacts are on Maven Central: https://repo1.maven.org/maven2/org/locationtech/jts/jts-core/1.18.2/ and GitHub https://github.com/locationtech/jts/releases/tag/jts-1.18.2
The Eclipse documentation is also updated: https://projects.eclipse.org/projects/locationtech.jts
and I've reset the JTSVersion.java and version history
I think at this point, we just need to announce this here (done!), on the dev email list, and on Twitter
Oh! I also have GT/GWC/GS PRs up
@dr-jts congrats on the release! Do you want to email the dev list?
@jodygarnett shout when you tweet something and I'll get CCR_inc to retweet it
Thanks for the GT/GWC/GS PRs i will review tomorrow
seems to me this was a bit more than a dot-dot release. Too late now of course, but I think we should be clearer on what is dot and what is dot-dot
Thoughts?
I question major: API change breaking compatibility. We do that fairly regularly! And I don't really want to get into JTS 2.x until rewrite time.
Here's my thought:
- major: rewrite, please send funding first.
- minor: new features, bug fixes. api change
- dot: minor improvements, bug fixes
what is the distinction between "API change maintaining compatibility" and "additive API change"?
So something like:
- major: you will need to port your application to use JTS 2.0 interfaces as Geometry is now an interface
- minor: we changed the api and your client code may have a compile error or new warning to fix
- dot: we fixed stuff, if we we changed the api your client code will not notice
It looks like JTS 1.18.2 had one class change locations so it could of been a minor release :P
The API change in JTS 1.18.2 is somewhat "soft"... a class changed packages, but the old class is still present but deprecated. Would this still be a minor?
Thinking ...
The old class is probably deprecated, so client code would get a new warning but still compile. I agree "soft" ...
So let me edit the above:
- major: you will need to port your application to use JTS 2.0 interfaces as Geometry is now an interface
- minor: we changed the api and your client code may have a compile error to fix
- dot: we fixed stuff, if we we changed the api your client code will compile, but may have a new warning to address
there is also semantic differences to take into account
(e.g. OverlayNG, which has some minor differences that people of course picked up on
"minor: we changed the api and your client code may have a compile error to fix, or a javadoc to read carefully for changed behaviour"
There is a school of thought (ie purist) that changes of behaviour should always be an api break
Hmmm... the Removed methods report is interesting. https://abi-laboratory.pro/index.php?view=compat_report&lang=java&l=jts-core&v1=1.18.1&v2=1.18.2&obj=9ab45&kind=bin#Removed
Shows that
CoordinateList.add() was removed, in this commit: https://github.com/locationtech/jts/commit/539ef272f20507cfd666f5c219f9af150b593604#diff-6557bc7f05fd4b213b0647f7457ac9c76c8dbff501ba38a1c040dc8e4f1bbb4d
(the big one that @jodygarnett made to start cleaning up the code)
Not sure why those had to be removed? And changes like that should be noted in the Version History under API changes, I think.
Of particular note is that this includes a fast Constrained Delaunay Triangulation for polygons, which gives much better quality.