Road to 1.0: Preparing trunk for prime-time and phasing out legacy-plugin branch

[felixarntz]

Version 0.2 of the plugin checker was recently released (see https://wordpress.org/plugins/plugin-check/) based on the legacy-plugin branch.

Other than bug fixes and critical enhancements, no changes should be pushed to the legacy-plugin branch.
This avoids duplicate work and prevents us from getting stuck in a place where the gaps between the two branches increases further. New 0.* releases with bug fixes should continue to be published from legacy-plugin branch as needed, but at the same time we need to focus on working towards a single codebase.

This issue should be used as an overview for which tasks (other issues) need to be addressed to switch from legacy-plugin to trunk and publish an eventual 1.0.0-beta.1 from there.

List of tasks / issues (please add anything else you can think of)

• Achieve check feature parity with plugin review team's current tool #253
• [Task] Replace references to 10up's repo with WordPress' repo ones (and other post-merge tasks) #256
• Add link to Plugin Editor for each found issue to jump user to file and line of code #251
• Implement persisting the enabled check categories checkboxes in user settings #299
• Update readme.txt contents to reflect the different use-cases and purposes of the plugin checker #300
• Implement plugin deploy workflow in trunk #302
• Implement readme parser check in trunk #322

[felixarntz]

@bordoni @mrfoxtalbot @EvanHerman @mukeshpanchal27 @joemcgill Opening this overview issue to log and holistically monitor the things we want to do before exclusively working from the trunk branch.

We'll want to make sure there are no feature gaps between the two branches, so I think with any new features and enhancements we should hold off working in legacy-plugin unless they are critical for the plugin review team's current needs.

On that note, how do you feel about #269? Wondering whether you're planning to implement this short-term in legacy-plugin, or whether we can do it only in trunk.

[bordoni]

@felixarntz You are 100% correct here, I would love for us to not take any more features or even enhancements on plugin-check.

To me #269 should be held for when we are working of trunk.

Tonight I will work on getting a couple of the PRs reviewed and checked. Also due to the move away from 10up organization we need to put some templates back for Issues and Pull Request creation.

[felixarntz]

Friendly ping here @bordoni @mrfoxtalbot @EvanHerman

It would be great if you could share an update on where the legacy plugin is currently at and what needs to happen for us to transition to using the trunk branch for the plugin checker.

[felixarntz]

I have opened new issues for what I currently estimate as the remaining work that needs to be done in #299, #300, and #302. All of these have been added to the description of this overview issue.

Please let me know if you have other things in mind that we should accomplish before switching to the trunk codebase. It would be great if we could launch a 1.0.0-beta.1 by end of this year, to remove the confusion between the two versions of the plugin checker sooner than later.

[felixarntz]

I have identified another issue that we should probably address for parity with the legacy-plugin, see #322. I've added it to the description above as well. This can be pick up at any time.

[joemcgill]

@bordoni now that you've gotten v0.2.2 released, can you share any additional updates about what needs to be done before we release 1.0.0 based on trunk, besides completing #322?

[mukeshpanchal27]

@felixarntz @joemcgill @eclarke1 Now that the list of issues for milestone 1.0.0 has been completed, what are the next steps?

[felixarntz]

@mukeshpanchal27 We are still waiting on an update from @bordoni and the other contributors to the legacy-plugin branch on whether anything is missing from their end to make the switch and release a first version of the trunk branch.

[foosantos]

Hi folks, we apologize for the delay in following up here. I'll share some initial details as an update, and @bordoni will complement this further today/tomorrow or clarify specific details if needed.

There were several changes that we had to handle before being able to use PCP Legacy in most environments, so version 0.2.2 of PCP delivers on that.

now that you've gotten v0.2.2 released, can you share any additional updates about what needs to be done before we release 1.0.0 based on trunk, besides completing #322?

While 0.2.2 works well now for plugin authors to self-check on WP installations, the primary goal is to add the PCP Legacy to the submission page on WP.org.

For this to be possible @bordoni is implementing a separate output handler so it can be used to output into the submission page. The goal here is to expose an array of all the data with their levels so we (or the meta team) can build a rendering method for that data on the Submission page.

After PCP Legacy is working on the submission page, we will need to review this plan for adding 1.0 in a way that works on the submission page. After chatting with folks on the meta team, one of the blockers is the use of Composer (as they wouldn't want that), so we will likely need to change the code to reflect that.

The expected timeline:

• Add the PCP Legacy to the submission page from January 31, 2024 to February 15, 2024
• Release of PCP 1.0 (including adding to the submission page) on June 15, 2024

[swissspidy]

After PCP Legacy is working on the submission page, we will need to review this plan for adding 1.0 in a way that works on the submission page.

I believe the 1.0 version is set up in a way that would make it very easy to add this new output format. Doing the same work twice for both versions seems like a wasted effort because it just duplicates work IMHO.

By making these changes directly to the 1.0 version we would accelerate this timeline automatically.

After chatting with folks on the meta team, one of the blockers is the use of Composer

What's the blocker specifically? Composer does not need to be installed on the server and the built plugin could very easily simply use a static class map for autoloading if there's a concern there. But some autoloading is needed as PHPCS is pulled in as a dependency.

[joemcgill]

Thanks @foosantos! I'd like to give a big +1 to everything that @swissspidy said above. I think continuing additional effort to integrate the legacy plugin into critical workflows while maintaining a separate version here in GitHub is not ideal, and it would be better to coordinate on a path to making the necessary updates to trunk and speeding up delivery of the new stable plugin everywhere.

In addition, if the necessary issues that need to be addressed can be tracked in this GitHub issue tracker, then several of us can help with the engineering and take some of the pressure off of @bordoni and the Plugin Review team. Having an expected timeline of 6 months, with no visibility in to a roadmap or issues to address does not seem acceptable and I would be very happy to support you and others in finding solutions to speed up that timeline.

[foosantos]

Hi folks! As @bordoni is directly responsible for the project from our end, I'm working with him to confirm some of your questions and next steps to follow up with you. I really appreciate your patience.

[dd32]

After chatting with folks on the meta team, one of the blockers is the use of Composer

What's the blocker specifically?

Composer was never a blocker. Anyone who suggested as such would've been expressing personal opinion. Composer based things are used in WordPress.org already.

[foosantos]

Hey folks, I had a call with @dd32 yesterday and one with @bordoni today to clarify some details.

• Gustavo had some personal issues, so he couldn't add a lot of time to the project in the last few weeks, but he confirmed with me that he is going to follow up today here. Gustavo also confirmed that he should have more time now to focus on the project again.
• Composer is indeed not a blocker, and one of the Meta folks misunderstood and shared the wrong info about this. I'll let Gustavo expand on that with all the specific technical blockers for already doing that with PCP 1.0 (instead of PCP Legacy).
• Based on what I chatted with Gustavo, he would still anyway have to review and confirm the test/check for using PCP 1.0 (as he was focused on PCP Legacy, thinking that PCP 1.0 was a big blocker).
• Gustavo has also worked on some code already to return the needed checks as an array for Dion, so authors will have a checklist to fix or skip (in case of false positive checks).

Gustavo, can you confirm the following:

• Do we still have blockers for PCP 1.0? If so, what are the blockers?
• How far are we going in adding the separate output handler on PCP Legacy vs. PCP 1.0?
• As Composer is no longer a blocker, if we decide to focus on PCP 1.0, how would this impact our timeline for adding to the submission page? Would we still have this on the submission page (with our top three needed checks) from January 31 to February 15?

I believe the decision to move focus to PCP 1.0 already would depend on how long it would take to add it to the submission page (while comparing it to PCP Legacy).

[bordoni]

As @foosantos talked about on the post about 3 days ago, I had some personal problems that prevented me from having any time to jump in here and reply.

Do we still have blockers for PCP 1.0? If so, what are the blockers?

Not anymore actually, if we can use composer as previously stated by Dion above, we should be in the clear.

We got the Checkbox to be persistent on a changeset that @felixarntz did earlier:
#299

With that my only ask is that the "Plugin Repo" should be the only one that comes checked by default to avoid confusion from new plugin developers.

How far are we going in adding the separate output handler on PCP Legacy vs. PCP 1.0?

I have something that I was going to add to the legacy version but based on the composer not being a requirement I feel like the correct choice is to focus on version 1.0.0 and pull that output from that version.

I will port my work to version 1.0 starting tonight and coordinate with the Meta team to include that version on the WordPress.org plugin submission form.

As Composer is no longer a blocker, if we decide to focus on PCP 1.0, how would this impact our timeline for adding to the submission page? Would we still have this on the submission page (with our top three needed checks) from January 31 to February 15?

I am hopeful that it shouldn't add much since the code build on version 1.0 allows me to deliver that HTML easily. I will confirm after talking to @tellyworth later today (2024-01-22).

---

I am doing some testing and making sure we are in a good spot to maybe launch version 1.0.0 with the changes that support the inclusion on the Plugin Submission form.

I will create the Issue here on the repository to make sure we have that work tracked.

[swissspidy]

With that my only ask is that the "Plugin Repo" should be the only one that comes checked by default to avoid confusion from new plugin developers.

This is now done ✅ as per #401

[foosantos]

Thank you so much, @swissspidy!

In this case, how do you folks feel about moving 1.0 to the plugin directory already? @bordoni, I believe we're ready for that in terms of checks and requirements, right?

Then, we can keep working on the output in the meantime, but with the new version already there. 🎉

[bordoni]

Thank you @swissspidy and @ernilambar for creating the issue and the PR about that.

This week I am working towards the output PR.I will keep working to make sure Dion and Alex have what they need to add it to the form, but in my eyes this should be a separate thing from us releasing version 1.0.0 to the plugin repository. What do you all think? @swissspidy @joemcgill @felixarntz

Maybe we should aim to start curating a Changelog for all the changes between version 0.3.X so we can prep for a 1.0.0 launch. I can take a stab but I think the folks from the performance team are more suited to get that started.

[swissspidy]

Sounds great 👍 This is very exciting! 🎉

Happy to help with getting this out of the door. With the automated GitHub Action workflow it should be trivial to publish 1.0.0 and any versions beyond that.

I just started #404 for collaborating on the changelog.

[swissspidy]

So the changelog in #404 got merged.

Now I just opened #407 to set up the automated deployment for the plugin. This way, we can tag a new release on GitHub and it will be automatically pushed to the plugin directory.

Since I don't have admin access to the repo, do we know whether the SVN_USERNAME and SVN_PASSWORD secrets are already populated? These need to be the credentials of someone who has commit access to the plugin.
If they're not yet added, I propose that the performanceteam user is granted commit access to the plugin. As this is a "bot" account, nobody has to store their personal credentials as secrets here. I think this is the best way. I do have those credentials, so if I'm granted admin access here I can add these as a secret.

@bordoni @foosantos If that sounds good to you, can you grant commit access for plugin-check to performanceteam? And then perhaps grant me admin access to the repo so I can add the secrets.

Then we should be able to launch with the click of a button :-)

Of course I'm happy to document the deploy workflow for future releases so that it's clear for everyone.

[swissspidy]

Oh, also, maybe we want to publish a blog post on make/plugins about this? This would close the loop on https://make.wordpress.org/plugins/2022/07/05/proposal-for-a-wordpress-plugin-checker/. What do you all think?

[swissspidy]

We're 99% set when it comes to shipping v1.0.0! Last remaining to-dos:

• Version numbers updated everywhere
• Build step finalized and final ZIP tested
• SVN credentials added to GitHub secrets for automated deployments
• Add performanceteam as a committer to the plugin
• Update main plugin filename
• Actually tag and release v1.0.0

While testing the ZIP file I noticed that v0.2.3's main plugin file is plugin.php and the one in trunk is plugin-check.php. If we keep that, this means when updating the already active plugin, the plugin it will be automatically deactivated because the file name changed.
To prevent this, I opened #419 to rename the file. Unless of course we don't feel like this is a big deal, since the plugin is not meant to be used on production sites anyway. However, it has like 400 active installs and changing a file name is not a big deal.

Edit: #419 is now merged

[swissspidy]

Plugin Check 1.0 is now available in the WordPress plugin directory 🎉

Thanks everyone for helping to make this happen!

Let's open new issues for any follow-up tasks.