Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare initial release #133

Closed
5 tasks done
felixarntz opened this issue Jan 28, 2022 · 18 comments · Fixed by #208
Closed
5 tasks done

Prepare initial release #133

felixarntz opened this issue Jan 28, 2022 · 18 comments · Fixed by #208
Assignees
Labels
Infrastructure Issues for the overall performance plugin infrastructure [Type] Epic A high-level project / epic that will encompass several sub-issues
Milestone

Comments

@felixarntz
Copy link
Member

felixarntz commented Jan 28, 2022

A lot of work has already gone into this plugin, so it's about time we get to the most important stuff - release it! 🚢

This issue should serve as a bit of an overview for the things we need to cover before our initial release. See the tasks below:

@felixarntz felixarntz added Infrastructure Issues for the overall performance plugin infrastructure Needs Decision Anything that needs a decision for next steps [Issue] Overview Provides an overview of a specific project Needs Discussion Anything that needs a discussion/agreement labels Jan 28, 2022
@felixarntz felixarntz added this to the 1.0.0-beta.1 milestone Jan 28, 2022
@felixarntz felixarntz self-assigned this Jan 28, 2022
@felixarntz felixarntz added this to Backlog in Infrastructure via automation Jan 28, 2022
@felixarntz
Copy link
Member Author

Please vote for this approach with a thumbs-up or thumbs-down emoji. Voting will close on 8 Feb 2022 at 6pm GMT.

The "easy" things first: Let's decide on the version number to use. Currently the milestone is named 1.0.0-beta.1 - which we can definitely change - however I'd like to suggest actually using 1.0.0-beta.1 for our first release since:

  • 1.0.0 is an appropriate first version.
  • The -beta.1 suffix should be there since we haven't done any beta testing before.

@felixarntz
Copy link
Member Author

In addition to the above vote, let's discuss a bit on the scope:

  • So far we only have the WebP for new image uploads module.
  • We're also about to have the first Site Health module, informing about excessive JS and CSS assets being loaded (see Add module to alert about excessive JS and CSS assets #54).
  • Both of these modules are definitely not in their final shape (e.g. the WebP implementation is pending a decision here, and the Site Health assets module needs follow-up enhancements already determined during PR review).
  • However, both of the modules are properly usable - they are not "broken" in any way and could be tested even in their current form.

My personal suggestion therefore is to limit our first release to these two modules, IMO that's good for a start. What I'm unsure about is at which stage we should ship them, should we wait for some of these more crucial enhancements being implemented first, or is it worth giving the current version out to people already (especially given that it would be a beta release anyway)?

Curious to hear y'all's thoughts!

cc @adamsilverstein @getsource @audrasjb @manuelRod @aristath

@JustinyAhin
Copy link
Member

@felixarntz let's also add "Create release assets" as part of the preparation. We will need a banner, a logo, and also screenshots.

@felixarntz
Copy link
Member Author

@JustinyAhin I agree that would be great to have, though I'm not sure it is a strict requirement. None of that is truly needed for a plugin. Again, I'm not saying we shouldn't have it, but I don't think it's a blocker to release. With that said, if we want to have a banner and a logo, I think we should reach out with the wider team as soon as possible and ask if there are any volunteer designers who would like to come up with something - maybe something for the chat tomorrow @bethanylang?

Regarding screenshots, we can definitely get that done.

@JustinyAhin
Copy link
Member

Again, I'm not saying we shouldn't have it, but I don't think it's a blocker to release.

@felixarntz I agree on that, let's not make it a blocker for the release.

Regarding screenshots, we can definitely get that done.

Yes, that will be a good start.

@eclarke1 eclarke1 removed the Needs Decision Anything that needs a decision for next steps label Feb 1, 2022
@eclarke1 eclarke1 moved this from Backlog to To do in Infrastructure Feb 4, 2022
@eclarke1 eclarke1 added the Needs Decision Anything that needs a decision for next steps label Feb 4, 2022
@bethanylang
Copy link
Contributor

bethanylang commented Feb 8, 2022

Clarifying here that the decision needed is for the vote on this comment: #133 (comment).

In addition, the Needs Discussion label for the scope: #133 (comment).

@adamsilverstein
Copy link
Member

My personal suggestion therefore is to limit our first release to these two modules,

This sounds fine as long as the release is clearly labeled beta, especially since the webp approach is changing significantly.

@bethanylang
Copy link
Contributor

Voting is now closed.

Based on 8 thumbs up votes and no thumbs down votes, we'll proceed with this behavior:

Using 1.0.0-beta.1 for our first release.

Removing the Needs Decision label. Discussion remains open for the scope items noted in #133 (comment).

@bethanylang bethanylang removed the Needs Decision Anything that needs a decision for next steps label Feb 8, 2022
@JustinyAhin
Copy link
Member

What I'm unsure about is at which stage we should ship them, should we wait for some of these more crucial enhancements being implemented first, or is it worth giving the current version out to people already (especially given that it would be a beta release anyway)?

About this, I think some enhancements have been addressed already.
#22 seems like to have a long way to go.

I'd suggest we release a beta version with the two modules in their current state, and iterate on the current issues/enhancements.

Releasing now also have the advantage of having more people testing the plugin, and more feedback as well.

cc @bethanylang @eclarke1 @felixarntz.

@felixarntz
Copy link
Member Author

The tricky part of shipping the current version of the WebP module would be that it will result in people's sites that use it no longer having JPEG sub-size versions of their JPEG uploads. This is probably not a big deal for many, but I'm wary of shipping it because it is in a way "destructive" behavior. I'd feel more comfortable if we had some implementation of having JPEG and WebP being generated.

@eclarke1 eclarke1 added [Type] Epic A high-level project / epic that will encompass several sub-issues and removed [Issue] Overview Provides an overview of a specific project labels Feb 15, 2022
@bethanylang
Copy link
Contributor

bethanylang commented Feb 15, 2022

Please vote for this approach with a thumbs-up or thumbs-down emoji. Voting will close on Tuesday 1 March 2022 at 6pm GMT.

Thumbs up 👍 : We will ship the initial release of the plugin with the WebP module in its current version, where it no longer generates JPEG images.

Thumbs down 👎 : We will ship the initial release of the plugin without the WebP module.

Heart ❤️ : We will delay the initial release until the WebP module has received support for generating both JPEG and WebP sizes.

We also welcome your thoughts on why you voted the way that you did in the comments on the issue. Thank you!

@bethanylang bethanylang added Needs Decision Anything that needs a decision for next steps and removed Needs Discussion Anything that needs a discussion/agreement labels Feb 15, 2022
@felixarntz
Copy link
Member Author

@bethanylang We may need to put a third option here like "We will delay the initial release until the WebP module has received support for generating both JPEG and WebP sizes." In that same sense, maybe the second option should be clarified that that would mean releasing a version that doesn't have the WebP module at all.

@bethanylang
Copy link
Contributor

@felixarntz Updated!

@felixarntz
Copy link
Member Author

Leaving an update here on the state of the WebP module: We still have the vote going on from #133 (comment) which ends March 1, but there is a chance that the essential parts of the webp-uploads module that facilitate the creation of both JPEG and WebP sub-size images will even be completed before then. The two particular issues that need to be completed for that are #142 and #149.

One more issue that would be great to complete before beta release is #61, since it touches default behavior of the overall plugin.

@bethanylang
Copy link
Contributor

Formally closing the vote here as the WebP module has received support for generating both JPEG and WebP sizes, so this is good to go for the initial release! 🎉

@bethanylang bethanylang removed the Needs Decision Anything that needs a decision for next steps label Mar 1, 2022
@felixarntz
Copy link
Member Author

Providing an update here after today's chat:

  • As discussed in the chat, we aim to publish the initial release 1.0.0-beta.1 on Monday, March 7. 🎉
  • In advance, I will prepare the repository for that initial deployment (configure the credentials) and draft a make.wordpress.org/core/ blog post announcement for the release.
  • On Monday, March 7 at 19:00 UTC we will have the "release party chat" in the performance Slack channel, in which we'll work through the release publishing tasks together. Anyone available and willing to help with the release is welcome to join!

@felixarntz
Copy link
Member Author

Important release update:

  • I have branched off from trunk into a new release/1.0.0-beta.1 branch and updated all relevant open PRs accordingly.
  • If you are creating PRs that fix something that is critical before the beta release, please work off that branch instead of trunk.
  • Any other PRs can be continued to be based off trunk. Those will then land in the following release when they are merged.

@felixarntz felixarntz moved this from To do to In progress in Infrastructure Mar 3, 2022
@felixarntz
Copy link
Member Author

Quick update: The plugin repository is now properly configured with the SVN_USERNAME and SVN_PASSWORD secrets to auto-deploy to wordpress.org (using the performanceteam account created for that purpose). So we are now technically set up for the release.

Infrastructure automation moved this from In progress to Done Mar 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Infrastructure Issues for the overall performance plugin infrastructure [Type] Epic A high-level project / epic that will encompass several sub-issues
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

5 participants