Migrate CI from travis-ci.org to travis-ci.com

[ChristophWWagner]

Seems that travis-ci.org is deprecated and should be migrated to the service under TLD .com

[ChristophWWagner]

Update: testing of master branch and pull requests is successfully migrated and the test coverage is extended to python 3.9, 3.10, 3.11 and the legay 2.7. Seems to work.

Next step: deployment. Following are my thoughts on this using some semi-manual process. Please comment (@SebastianSemper ?).

• Whenever a new version shall be deployed we create a PR from master to stable. Probably it's not even necessary to restrict the branch from which to merge, since only a few people can merge to stable, so using some intermediate branch could be fine (suggestion: release-candidate-$(VERSION)).
• Using this intermediate branch it is possible to adapt any CI issues transparently without cluttering any of the protected branches (master or stable).
• A new workflow will take care of building all wheels and distributions as a prerequisite for a successful merge
• Once merged, another workflow (triggered by a new commit to stable) will also perform uploading. If it is possible to reuse the build artifacts from the previous PR run, that could help.
• Another nice-to-have would be to split the current testing workflow to reduce the amount of CI runs for regular merge testing.

[SebastianSemper]

Sounds good. I think many OSS project operate like this.

Regarding deployment, I am wondering if it is really necessary to upload packages automatically using CI, since releases are rare enough and our wheels are very generic. We could also simply put some mimic in the makefile and execute this after releases to stable.

[ChristophWWagner]

d0ne.