Create new release to fix deprecation warnings

[danepowell]

Anyone installing phpcs-security-audit via Composer now gets warnings like this:

Deprecation Notice: Class PHPCS_SecurityAudit\Sniffs\Drupal8\CVE20132110Sniff located in ./vendor/pheromone/phpcs-security-audit/Security/Sniffs/CVE/20132110Sniff.php does not comply with psr-4 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///home/dane/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201

This is due to a bug that I think was fix in master, but it has not been released. In fact there hasn't been a stable release since last year.

Could we please get a new stable release to fix these issues?

[danepowell]

Note that Composer 2 will be released in a few weeks, at which point these won't be just warnings any more, but potentially critical errors.

[danepowell]

@jmarcil or @jrfnl looks like maybe you are the maintainers, are you able to cut a release?

[jrfnl]

@danepowell I'm not an official maintainer, but if we're talking Composer 2.0, PR #82 will need to be merged before any release.

[danepowell]

I'm not talking about supporting Composer 2, I'm just talking about getting rid of the scary (to some people, especially our customers) yellow warnings for Composer 1 users. I think these warnings were already fixed in master, all we need is a new stable release (i.e. 2.0.2) to take advantage of the fix.

Composer 2 support is of course important as well, but not as immediate :)

[phily245]

We've just tested & locked to a specific commit on master to support composer v2 alpha testing and remove the deprecation warnings, a return to semver would be good :)

Wish I could submit a PR for this!

[jmarcil]

Hello everyone!

I'm sadly currently the sole maintainer of this project, and hopefully we all can fix this soon.

With what is happening in the world this year, this project has been hard backlogged on my end. I won't have time to verify and merge PRs anymore for the foreseeable future. Same goes of course with any required fix, code modifications or documentation changes.

I've asked around and I'm ready to move this repository to it's own GitHub organization, where people can be added as collaborators. I'm more than willing to give away merge and other required access. I'll remain the primary owner to manage the org itself.

So two questions:

1. Can you see what will break if I do the organization move right now?
2. Who wants to join in?

[danepowell]

@jmarcil I understand and sympathize with those challenges, and don't want to create more work for you. We're not asking for any new development as part of this ticket, all we need is a release tag, would you be able to accommodate that?

[jrfnl]

@jmarcil

1. Can you see what will break if I do the organization move right now?

As long as the name in the composer.json file doesn't change, this will not break anything for Composer users.
And as long as the move is done by using the GH "Transfer repo" feature, GH will automatically redirect to the moved repo for all typical uses (clone commands used in CI, forks linked to this repo, bookmarked URLs etc).

So I currently can't think of anything which would break.

I would recommend mentioning it in the changelog all the same.

2. Who wants to join in?

See my previous reply to this: #56 (comment)