Stable or beta 4.x D11-compatible release

Anyone any insights on this?

The voting entity needs some backwards-incompatible changes. Until someone writes an update function to update existing sites for those changes, I'm not going to make a "stable" release because that would be lying about the status of this module and giving you false expectations. "Beta" is a better description of the current code, until this problem gets sorted out.

In reality, since there is almost no community contribution to this module, what I will probably end up doing is to make a new major branch with these changes and without an upgrade path. I don't have time to work on writing the entity update functions and I don't expect to get any testing from community for any update functions, and I don't have a large site with Voting API data that I can use to develop and test them myself.

I will gladly work with anyone who wants to write these update functions, but I'm not planning on doing that myself.

Can we please have a stable or beta release for the module.

Hi tr,

Drupal 10 is scheduled for EOL in just under a year, which is not a lot of time considering there's no D11 release. This contrib has been really useful, but I can't see how much progress has been made towards Drupal 11 compatibility, other than a 4.0.x-dev branch that was last updated about 9 months ago in March.

In order to involve the community a bit more, what are your thoughts on the following suggestions?

• Create a beta, or alpha, release of the current 4.0.x-dev branch.
• Use this ticket to track issues that are blocking a stable release.

Upgrading to critical given D10 EOL later this year.

I'm using dev-version on production. I think current dev-version is really stable

I'm researching whether to use the API on a new D11 site. After creating a proof of concept, the dev version of 4.0 seems to work for my use cases so far.

However, I'm hesitant to use a dev version that hasn't had updates for a long time. What are the specific blockers for releasing a stable version? What are the child issues that need to be resolved?

Are more maintainers needed?

Since 4.x is a major release, I suggest we declare it as not backwards compatible (BC) for now to give some clarity to the community and move forward.

@papagrande this is "Rogue Developer Scenario". The current maintainer has taken over several projects. He doesn't work on them properly and doesn't allow others to become maintainers. Unfortunately, Drupal.org can't do anything about this.

@krakenbite Wrong in many respects. The module has several maintainers, not just one:

https://git.drupalcode.org/project/votingapi/-/project_members?sort=acce...

If someone else wanted to become a maintainer, they could apply through the Drupal.org project ownership:

https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or...

Last and most importantly, nobody has taken the time here to comprehensively respond to tr's concerns about backwards compatibility and update hooks. Seems to me the path is as straightforward as digging in, validating or invalidating those concerns, posting next steps, providing whatever code updates are required, getting code review, getting it merged. We all know the drill here.

Helping is helpful. Negging the maintainer is not helpful. In fact, we really don't want to normalize pressure campaigns against volunteer maintainers because that's how you get hacks like the XZ Utils backdoor.

That said, if any maintainers have eyes on this, it would be very helpful to get at least a beta release of the 4.x branch.

Wrong in many respects

Not wrong. I've been following this project for a long time and I know everything that's going on.

The module has several maintainers

But the last commit from other maintainer was Jul 22, 2020. Tim Rohaly the "active" maintainer since that date

If someone else wanted to become a maintainer, they could apply through the Drupal.org project ownership

They tries. But Tim Rohaly reject all requests as "active" maintainer