Moving Connexion forward

[RobbeSneyders]

Hi all,

Like a lot of other people here, we are convinced of the benefits of Connexion but worried by about the state of maintenance of the project (#1262, #1334). After a comparison with other available and popular tools, we decided that Connexion is still the best framework for our needs, as long as it is actively maintained. Since we're not aware of any existing maintained fork, we want to commit to help maintain the project ourselves.

We have created a fork and are actively working on adding our own improvements. So far we have:

• Added support for multiple authentication methods (Add support for multiple security schemes in AND fashion ml6team/connexion#1)
• Moved CI/CD to github actions so the tests can run on our fork
• Fixed the tests and added version upper bounds for breaking dependencies
• Added high level documentation (Add ARCHITECTURE.rst and module docstrings ml6team/connexion#6)

Our goal for the project is two-fold

• Provide regular releases with continuous improvements and bug fixes
• Continue the work towards a framework agnostic Connexion 3.0 with support for frameworks such as quart, sanic & starlette (Framework-agnostic Connexion #380, Support for sanic/starlette framework or async/await #496, Support Sanic #1250, WIP: Run framework agnostic tests #828, WIP Harmonize serialization between aiohttp and flask #1095, Feature/quart Ruwann/connexion#3)

The goal of this fork is not to do a hostile takeover, but to ensure that Connexion and its API-first approach can stay alive and be extended to other frameworks. We created the new fork to start moving forward again, but are convinced that it would be better for the project to be able to keep its home and name. @hjacobs @jmcs @rafaelcaricio @dtkav, if you read this, please reach out to discuss any possibilities of collaboration on the current repository instead.

If there is no possibility to keep working on the current repository, we'll open discussions on how to move forward with the fork in the coming weeks. So make sure to star / watch the fork or this thread to stay up to date. In the meantime, feel free to already submit any issues or pull requests on the fork as well.

@RobbeSneyders @Ruwann @svetlana-v

[dtkav]

Awesome! I don't have write permissions to the repo (I was also a community contributor), so I can't help you. I might be interested in contributing to the fork! I have some open PRs I'm excited about.

IMO the ideal course of action would be for Zalando to donate the project / branding. That way they aren't legally bound to review every PR when they don't have the resources to do so.

Best of luck to you!

[rafaelcaricio]

I'm in the same position as @dtkav . When I worked at Zalando I used to have permissions to the repository. In the last 4 years I didn't have any access. I need someone from Zalando to merge PRs, approve, etc.

I agree that it would be best for the project to move to its own organization in Github. But that is my personal opinion.

I hope this can be fixed.

[hjacobs]

As discussed in a video call today with @jmcs @hjacobs @rafaelcaricio @RobbeSneyders @Ruwann @Fematich:

• Zalando will give write access to this repository to @rafaelcaricio @RobbeSneyders @Ruwann in order to move forward with the project and incorporate long outstanding changes.
• @RobbeSneyders @Ruwann will be added as maintainers to the MAINTAINERS file
• @hjacobs will figure out until June 25 EOB how to work with Zalando compliance rules and PR (Zappr) approvals. For the time being it requires a "+1" from Zalando organization member in order to merge to master --- PRs can be merged to main.
• We will switch from master to main as the default branch
• We will move from Travis to GitHub actions for CI/CD
• A proposal will be made on how to move Connexion into a separate organization --- this also requires approval from Zalando side
• Still to be discussed: how to release a new version on PyPI and how to version (breaking changes etc) --- preferred are small incremental changes (bugfixes) and then working towards a major new release cleaning up the code. A roadmap will be needed.
• @jmcs @hjacobs @rafaelcaricio @RobbeSneyders @Ruwann @Fematich will have a check-in video call in two weeks. @RobbeSneyders will schedule the call.

@dtkav as you were not part of the video call, if you want to be an active maintainer with write access, please let us know here.

[dtkav]

I'm interested in helping but my availability will be on and off over the next few months (kid on the way). I'd be interested in tuning in for future synchronous meetings if possible. We're retrofitting our API at Benchling (my dayjob) with OpenAPI validation, and we're using openapi-python-client for our SDK, so I definitely have some lessons-learned w.r.t python 3 and evolving a typed interface in a backwards compatible way.

@cognifloyd was also a big help a while back. They might be a great resource too.

[RobbeSneyders]

Thanks for the overview @hjacobs. Very happy with the outcome of our sync.

Regarding the fork, we'll move any changes we already did to this repo in the coming days and close the fork afterwards.

@dtkav I already included you using the e-mail address listed in the MAINTAINERS file. Let me know if this doesn't work for you and how I can include you instead.

[drewsonne]

This is great news!

Any chance we could get the main branch released to pypi before moving on with the greater plan?

I got a PR merged to main/master last year, and we've been using a custom RestyResolver waiting for a release to pypi before removing our custom code.

[hjacobs]

@drewsonne we could release the pending changes (2.7.0...main) as version 2.8.0.