Release schedule for 1.17?

[jagill]

Do we have any schedule for releasing 1.17 (or a bugfix 1.16.2)? In addition to bug #490, there's blocking bug for me that is fixed on master but not in 1.16.1. For a Presto release, we'd need to pin to a released version of JTS.

For context, the bug is an off-by-one error in PackedCoordinateSequence that causes an IndexOutOfBounds exception.

---

Release activities from RELEASING.md

• update release notes (see JTS_Version_History )
• experiment: review fixed issue and assign to 1.17.0 milestone
• release process (resulting in a tag)
• submit for eclipse foundation review (a two week window for feedback)
• release to maven central

[dr-jts]

No release schedule yet, but it is probably time for a release.

[jagill]

Just following up. It seems like there's been a bunch of awesome bug fixes since 1.16.1 (and some unblock me). Should we set a release schedule?

[dmitrykinakh]

@dr-jts - when we can expect a new release? In my project, I'm using jts-core-1.15.0-SNAPSHOT version but have an issue with that at it eat 100% CPU. Hoping new version can fix that.

[dr-jts]

@dmitrykinakh I'm intending to release 1.17 before FOSS4G in August.

If you have a problem with 1.15 perhaps you should try 1.16.1?

[jnh5y]

@dr-jts Good to hear a schedule like that. Is there a timeline that we should fire up some testing with GeoTools and GeoServer?

[dmitrykinakh]

@dr-jts I've already tried that, unfortunately, indexing 400 items (and even 100) per batch in 3 million datasets still lead to 100% CPU usage.

[mprins]

@dmitrykinakh Did you try with a JTS snapshot build in your project?

You only need to add https://repo.locationtech.org/content/repositories/jts-snapshots/ as a snapshot repo to your project and you can use 1.17.0-SNAPSHOT

[dmitrykinakh]

@mprins - thanks for your comment.

I'm not really good at DevOps staff and yesterday did this as a quick test.

Is this link is a valid one for the recent 1.17 snapshot?
https://repo.eclipse.org/content/repositories/jts-snapshots/org/locationtech/jts/jts-core/1.17.0-SNAPSHOT/

[mprins]

that is the correct directory, yes; you'll notice that artifacts are timestamped.

it looks like you are not building a Maven project, but constructing a solr docker image, so I can't help you there. Also not clear why you think a newer version of JTS would fix your problem with solr?

[dmitrykinakh]

I'm not sure if newer JTS will fix my issue but what I'm sure about is that I have a 100% CPU usage when I index data with geometry (polygons) and have low CPU usage (25-30%) when I turn off geometry field from indexing.

So, I just want to try of I'll get some improvements in terms of performance with a new version of JTS as it's used to index geometry.

[jnh5y]

@dmitrykinakh The Solr and Lucene communities have implemented various other geospatial capabilities some of which use JTS and some which eschew it. It may be worthwhile to get in touch with those communities about your speed concerns. If JTS is used, they can explain how and discuss options for improving performance.

[jnh5y]

Also, since @mprins mentioned it, I wanted to own to the fact that the JTS nightly snapshot builds are broken. It is on my list to address this, but I'm behind on knocking it out.

[dmitrykinakh]

@jnh5y - could you mention/link me with any of the community that can help me to debug my issue with indexing geometry?

[jnh5y]

@dmitrykinakh Sorry I don't have any particular pointers. I'd suggest just asking on any Solr user lists, etc.

[jodygarnett]

@jagill as you were kind enough to provide this bug, I would like to use it to coordinate the release :)

If you are available to help test that would be appreciated.

[jagill]

@jodygarnett I'm happy to check that the new version fixes the issues I mentioned. Additionally, I'd be happy to run the release version through our Presto test suite, which tests many standard and edge cases, and also the verifier, which will randomly select thousands of queries for any correctness changes or significant performance regressions.

[jagill]

@jodygarnett I checked, and 1.17.0 fixes the issues I mentioned before. The results from buffer seem to have changed by a small amount -- some double coordinates have changed by about 1e-15 or so. Well within tolerance, of course, but enough that verifying results will be a bit more effort.

I haven't been able to run this on our verifier geospatial query suite, but I hope to get that done as soon as the slots open up.