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

What we need are people who can spend some time for this project.

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

Why not at least release a beta6 then? Did someone ping the maintainers and ask if they are still active?

Yes, I think it would be good if compatibility with Drupal 11 were ensured.
When can we expect that?
Thanks for your work.

I'd be willing to try and help address the concerns if It helps get a release out. I understand the gist of his concerns but at this point I'm not clear on exactly what the incompatible changes would be that need tests. If we could maybe identify issues that where non-bc changes, or specific code changes, or some other specifics and maybe get those in the IS summary that might help the people with eyes on it move forward with tests and or update/migrate functions.

didn't mean to assign, was planning on doing that and making the changes but realized I didn't know what was needed.

I maintain Voting API Reaction, which depends on Voting API, and I would like to help unblock a Drupal 11-compatible Voting API release.

From the discussion, it sounds like the main blocker is not basic Drupal 11 compatibility, but confidence around the Vote/VoteResult entity changes and whether an update path is required, especially the work tracked in #3153550: Vote entity unnecessarily re-implements features provided by base class

I can help by testing an upgrade path from 3.0.0-beta5 to 4.0.x-dev with real vote data and modules depending on Voting API, including Voting API Reaction. I can also help document whether database updates are actually required, and if they are, work on the needed update hook/tests.

Would that be useful here? If yes, I think the immediate goal should be a clear checklist for a 4.0.0-beta1 release, with stable release work following after the upgrade path is proven.

I appreciate that this is the issue for the 4.x version of the module, but might a decent path to Drupal 11 support be something like:

1. Get a 8.x-3.0-beta6 out, with very basic D11 support, keeping whatever bugs etc. we have in the codebase already
2. Work on getting 4.0.x polished and testable alongside 8.x-3.0-beta6, with an upgrade path where possible.
3. Move to getting a 4.0.x beta

I had a quick look at the changes between the 8.x-3.0-beta5 and latest 4.0.x: https://git.drupalcode.org/project/votingapi/-/compare/8.x-3.0-beta5...4... and that looks like quite a lot! And if there are BC breaks, then that seems a bit scary to do all of that change in one go?

Since it's been brought up in this thread, @TR (and other maintainers) would you be open to someone helping to co-maintain Voting API to get a Drupal 11 release out, and coordinate getting the 4.0.x branch polished to the point where it can get beta releases etc.? Or is that a non-starter.
Seems like we need to work out a way forward here as a community.
There's only four and a half months until Drupal 10 is EOL, so I suggest we need to get a wriggle on and get something compatible with Drupal 11 out there (that isn't a dev version.)

I've put the proposal for another 8.x-3.x version in #3610833: Beta version of 8.x-3.0 that supports Drupal 11 and raised a proper ticket to discuss adding me as a co-maintainer here: #3610834: Offering to co-maintain Voting API.

I'm a co-maintainer now, so watch this space / issue: #3610833: Beta version of 8.x-3.0 that supports Drupal 11

Thanks, @steven jones, for stepping up.

If you split out child tasks, the community can help get them done ASAP in parallel.

I think it's #3153550: Vote entity unnecessarily re-implements features provided by base class that needs doing, and then for me to be comfortable doing a release I think I'd need some time to review all the changes.

From the sounds of it some folk are already on a development release, and maybe doing a 'stable' alpha/beta would be a good idea to help them avoid dev releases.