Release 1.1

[Thrameos]

• [x] Start from the release branch git checkout release
• [x] Make a new branch for the release cycle git checkout -b releases/{version}
• [x] Merge the current master with the release git pull origin master
• [x] Start a release bumpversion release
• [x] Edit doc/CHANGELOG.rst
• [x] Send the release to be evaluated git push
• [x] Verify CI on azure
• [x] Manually trigger a jpype.release on azure If successful, download the artifacts for publication.
• [x] Advance the release pointer git checkout release git merge releases/<version>
• [x] Publish the release
  • Add draft release on github
  • Attach the artifacts to the release.
• [ ] Start master on a new cycle
  • Use a PR to pull release back to master
  • git checkout master
  • git checkout -b cycle
  • git merge release
  • bumpversion patch
  • Use PR to insert the cycle in master

[Thrameos]

Needs some fixes to the release process scripts. Resolve is not being called properly so some of the builds are failing. These should have been pulled as artifacts from earlier stages. Further investigation is required.

[Thrameos]

@marscher I had to disable some of the tests during the release stage of the project. The tests passed in the build portion so I don't believe there is any issue, but for some reason I can't get it to pick up jedi and the jdbc jars on windows and osx due to some file structure issues in the test machine. It is tough to resolve as it takes about 30 minutes to cycle for each change in the release so I added those tests to the "--fast" test skip list and set that flag for the release testing procedures. Given this is all extra stuff in the release path I think it should be safe.

Assuming that is fine with you we can copy the release artifacts over and publish 1.1.0.

After this release the next big project remains the reverse bridge. I have a prototype of the system but there are a lot just plain typing type tasks where I need to manually copy over APIs that need to be exposed, then resolve all the patterns, and then automate those patterns. Alternatively we can press towards improving the wrapping functions of the bridge by allowing an API to get into the dispatch and add methods, remove/disable methods, set the return converter, or add individual adapters, set method resolution precedence. Both are pretty big advancements, but it is not yet clear which one will depend on the other. I suspect the some things will get much easier once the first is complete as we will be able to store Python objects in Java directly and use them in the Java land to for resolving things. The second does require me to rename the internal API for JMethod to JMethodDispatch so that java.lang.reflect.Method instances can be exposed as usable objects. I am not sure if I can make that change without bumping the library to 2.0 though as although this should be entirely outside the user space it does change names in the internal hierarchy.

[marscher]

Thanks for pushing the new release. It is a major improvement and contains lots of bug fixes and I especially like the new database interface. I'd be glad, if we could support Python-3.9 as well. I think we currently do not have it in our testing matrix, so we should add it soon and build the wheels for PyPI.

[marscher]

There is an issue with the versioning semantics, which some PEP requires(or recommends):

python3.6/site-packages/setuptools/dist.py:452: UserWarning: Normalizing '1.1.1_dev0' to '1.1.1.dev0'
  warnings.warn(tmpl.format(**locals()))

But this only applies to the dev version so it does not hurt anybody.

[Thrameos]

Yeah I noticed that one, but attempting to make the underscore into a dot in bumpversion broke it from advancing releases so I decided to leave it for now.