Roadmap for a 3.x 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.

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 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 #3518252: Add _csrf_confirm_form_route option for to the user/logout route To a list of issue that should be fixed before first beta. Maintainer needs help there doing manual testing.

Agree, a full release can also be checked by the Security Advisory which is greatly appreciated with this kind of module.

#3518252: Add _csrf_confirm_form_route option for to the user/logout route was committed but hasn't been included in a release yet - does that suggest a first beta, or at least another alpha could be tagged please?

FWIW, I need https://git.drupalcode.org/project/openid_connect/-/commit/6052cff18ea87... to update smoothly from 8.x-1.x, and that's not in a tagged release yet either.

Once these three land, I'll get the alpha7 tagged.

- https://www.drupal.org/project/openid_connect/issues/3537149
- https://www.drupal.org/project/openid_connect/issues/3497559
- https://www.drupal.org/project/openid_connect/issues/3359789

I haven't seen anything else critical in the issue queue that I think would have any API changes. Once I review the backlog again and confirm, I think beta1 will be tagged shortly thereafter.

I would also do this one:

- https://www.drupal.org/project/openid_connect/issues/3541600

Else a lot of people are going to complain on the extra logout step. It can be patched, but additional config in a patch is always dicey.

Linking to issues listed in #18

Optionally disable logout confirmation (3541600) should not be blocking next release.

while it's a nice feature to have, imho it should not postpone the beta release.

@xlyz #21 yes, perhaps that is a feature that can be added later in the stable phase.

+1 - This is a blocker for upgrading projects to Drupal 11.

I've been using 3.0@alpha successfully in production for more than 2 years.

This is a critical blocker for our upgrade path. A stable release is required before we can proceed with upgrading projects to Drupal 11. Please prioritize this issue.

Would be nice, to have #3266205: PKCE Parameter Support in a v3 release too.

We are about to hit 1 year since the last alpha. There's 9 commits on 3.x since 3.0.0-alpha6. Can we at least get a new alpha?

In drupalcode there is no activity since August. Anybody willing to step up?

Someone could ping a maintainer.

I updated the links in the issue summary and added a link to open bugs in the 3.* group.

It seems there's just 1 critical and 6 majors right now. The list of bugs is a bit longer, but not everything needs to be fixed before a stable is cut. I'm not sure which, if any, are truly release blockers on those lists.

(hit submit a little early, sorry for the half comment to anyone who gets email notifications)

I added a documentation issue: #3582142: Update documentation for the 3.x branch. I think that should be done before, or along with, a 3.0.0 release.