cebe
Further library maintenance
@cebe Please make a decision and/or statement on whether:
- this library is abandoned by you, and you are unsure what to do about it
- the library is abandoned, and you will assign a maintainer for it
- or you are busy at the moment, but will return to maintaining the library in some foreseeable future
- if you plan to further develop this lib only if you get a payment for it, and do not consider having other maintainers (but then it's IMO the worst scenario, the community will just gradually switch to a fork)
the library is abandoned, please consider negotiating a maintainer for it, or point to the fork which will officially become the successor of this lib, although IMO it's better to keep the original library evolving.
If you fear that the new maintainer will not keep up to the same quality standards as you have in mind, give them some rough guidelines, it should not take too much of your time. Also you could do some occasional reviews if you wish.
There is a guy who already maintains a fork, he might be a good candidate, and I can suggest myself too!
The community can cope on its own, but it would be MUCH nicer and convenient if the transition process was official. Thank you!
Does anyone have an up-to date fork with php 8.2 and maybe OpenAPI 3.1 support until this issue is resolved?
@cebe Any update on this? Thank you so much for your contributions this far, and please don't feel pressure to continue if you don't want to/can't. But it would be good to know if this repository is archived.
Hi all, and sorry for the late reply!
As you might have guessed I'm busy with a lot of other stuff and have not enough time to care about my open source projects right now. However I am using this library myself in production so I am not considering to abandon it. We are actively developing yii2-openapi and yii2-app-api, which rely on it.
I'd love to return all improvements that are being made in forks back into the library and I might add some people as maintainers here. As I have not been able to follow the Issues and PRs for quite some time, I'm not in a position to invite maintainers right now. I'm open for input on this. Wo wants to join a maintainer team for php-openapi? Which forks should be considered for merging back?
I'll try to make some time to review what has happened here and try to bring the library back to live. I'll also monitor this issue so you could expect an answer for anything written in here.
best regards, Carsten
Who wants to join a maintainer team for php-openapi? Which forks should be considered for merging back?
There is a (semi-)active fork: https://github.com/DEVizzent/cebe-php-openapi and it seems its maintainer can be a fit for the team. I cannot decide for him though, hence I also suggest myself. I can find few spare hours a week to go through PRs at minimum, and perhaps to contribute as well (but not a lot of my time though).
I would prefer some guidelines and "vision", but even without it I can infer it from the "surrounding" code. An example of "vision"-related decision is to whether to keep 3.1.0 and 3.0.0 OpenAPI support as separate entities in the lib, or support them both in more generic way (as I understood, the latter was chosen). Also, whether all new code should be tested (I think it should), should the "refactoring" and "feature"/"bugfix" PRs be separated etc.
Around a year ago I started on https://github.com/kynx/mezzio-openapi-generator. It basically works, at least for us. The code it generates is in production, but there are things I want to clean up.
I don’t think making 3.0 and 3.1 separate is worth the maintenance effort. There aren’t a lot of people here: if you want 3.0, use the (security-only updates) existing code; if you want 3.1, use next major and get the improvements.
Vision? I hate magic methods. The docblocks on a bunch of them are just wrong. I was keeping a list but gave up and put asserts everywhere in my code so psalm stopped barfing.
Changing that is a big refactor, but unless this library can survive static analysis it doesn’t have a future. And neither does it the work I’ve based on it.
OpenApi’s query param syntax is a complete dog’s breakfast. They lead you down a path thinking that it can be mapped to uri-template: it can’t. There needs to be a separate php library just for creating, parsing and validating that mess, preferably reused in https://github.com/thephpleague/openapi-psr7-validator and https://github.com/janephp/open-api-3
I’d be willingly to do that last one, and will certainly be reviewing whatever happens here. But I’ve got to support my existing projects, and until this thread woke up (thanks @cebe !) was looking at rewriting them in Go ☹️
hey @cebe first of all. Merry christmas :christmas_tree: Do you already know when and who you would like to add as a maintainer here?
I started a new fork in an global namespace and would also add more people who want to join the project and put some more update into this Project again. Thanks again cebe for the work you invested here already. I also invited you to the project with write access.
https://github.com/openapi-php/php-openapi/releases/tag/2.0
There's already maintained https://packagist.org/packages/devizzent/cebe-php-openapi
On Sat, Feb 17, 2024, 22:38 Marcel Thole @.***> wrote:
I started a new fork in an global namespace and would also add more people who want to join the project and put some more update into this Project again. Thanks again cebe for the work you invested here already. I also invited you to the project with write access.
https://github.com/openapi-php/php-openapi/releases/tag/2.0
— Reply to this email directly, view it on GitHub https://github.com/cebe/php-openapi/issues/190#issuecomment-1950379055, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACQAJKNIW7674I4HZLOOQDYUEPO3AVCNFSM6AAAAAA2SWUW7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJQGM3TSMBVGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
@marcelthole
Is this now the state...?
credit: https://xkcd.com/927/
Seems suboptimal to me...
