Is 3 alpha ready for production and what is the roadmap for a production release

I was wondering this, too. The 8.x-1.x releases are marked as recommended, yet they have many fewer features, fewer fixes, and half as many reported installs (6k vs 12k).

At this moment, the main objective is to make sure that the 3.x branch works on Drupal 11. I'd love that someone that actively used this module would be interested in taking it over. One of my objectives with the 3.x branch would use the code from https://oauth2-client.thephpleague.com/ in order to have a sane codebase. Not sure if that objective is realistic, as the small add-ons for OIDC added to this module may not be possible with the pure OAuth 2.0 code that that package uses.

Given there are already 12000+ sites using 3.x I'd suggest releasing a stable version of what's in the alpha that supports 11.x, and open up a 4.x branch to investigate the package mentioned in #4.

I agree with the idea of releasing a stable version of what's there right now in 3.x and then starting 4.x to start implementing oauth2-client.

@jcnventura regarding finding another maintainer, this project already has five! Has it not really been maintained?

I would like to make a further suggestion:

• Release 3.0.0 based on 3.0.0-alpha3. Provide only security support for the 3.0.x branch; no other development.
• Open branch 3.1.x. Set the minimum to Drupal 10.3 (no Drupal 9 support). Implement Drupal 11 compatibility only here.

This gets around the challenges of supporting Drupal 11 along with much older versions of Drupal while avoiding dropping support for older versions in a patch-level release.

A release plan of first beta/RC allowing the maintainers to list what is currently "blocking" a stable release? Would also allow users to jump in on those issue and perhaps help out getting them tested and merged. The maintainers are very active, but it would be helpful (at least to me) to see a release plan. Still on alpha often means there are features missing...

I second #6 💬 Is 3 alpha ready for production and what is the roadmap for a production release Active .

Currently Keycloak OpenID Connect has dropped 8.x, and current release (2.2.1) requires v3.x, that is still alpha. In any case we need to pick a non supported solution. Not a good feeling :-).

Thanks for the feedback everyone. I understand the concerns of being forced into using an alpha. I can assure you the 3.x branch is definitely maintained.

I think next steps are to come up with a realistic list of existing bugs that need to be completed before going beta/stable. From there, we can start working toward that milestone. One of my main goals is to get test coverage up on almost everything.

I definitely want to get to the 4.x branch and @jcnventura's suggestions of using the PHP Leagues Oauth implementations, but we need a stable 3.x first.

I think the worry is around how you define Alpha.

My worry is if there are going to be any significant, backward incompatible, changes to the software. I'd say if you consider this to be Feature Frozen then it should, at least, be considered a beta --even in it's current state.

I think any any significant, backward incompatible changes should be done only in 4.x so that 3.x can be stable. The majority of openid_connect users are on 3.0.x already, so big changes need to be avoided.

It doesn't need to be bug-free before getting a stable tag. It would probably be reasonable to give it a stable tag now and continue with bug fixes in patch-level releases.

Having a stable release would allow people to start moving off the very old 8.x-1.4 and upgrade to Drupal 11.

@frob wrote:

I think the worry is around how you define Alpha.

My worry is if there are going to be any significant, backward incompatible, changes to the software. I'd say if you consider this to be Feature Frozen then it should, at least, be considered a beta --even in it's current state.

Here I have to agree. Alpha to me, indicate that there is more than bugs and missing tests needed to be fixed, but non of that mention in #10. If not, I would love for us changing to a beta tag.

• Critical open: https://www.drupal.org/project/issues/openid_connect?text=&status=Open&p... →
• Major open: https://www.drupal.org/project/issues/openid_connect?text=&status=Open&p... →

for reference:

Beta releases

Beta releases are usually only created once:

• All critical data loss and security bugs are resolved
• The APIs are frozen enough so that contributed module and theme authors can start upgrading their projects.
• Most of the problems with the upgrade path are fixed and it's possible to successfully upgrade a copy of the Drupal.org database to the new Drupal version.

from Drupal > Getting started > Understanding Drupal > Understanding Drupal version numbers: What are alpha and beta releases, and release candidates? →

I could live with a beta :-)

I nominate ✨ Add _csrf_confirm_form_route option for to the user/logout route Active To a list of issue that should be fixed before first beta. Maintainer needs help there doing manual testing.