1.2.3 Milestone Discussion

[bacoords]

I've set up a new milestone for 1.2.3 that would be a quicker release than some of the bigger (potentially breaking) changes that would be better suited for 1.3. Here's what I'm thinking so far, but open to discussion:

• Fix TinyMCE body margin #2073
• Bump Bootstrap from 5.2.2 to 5.2.3 & other dependencies #2010
• Improve readability of sidebar templates #2071
• Fix typo in .gitignore to track .browserslistrc #2118
• Make Babel compile Bootstrap imports #2035
• Add and update WooCommerce templates #2091
• Adds BS container classes and max-widths to editor styles #2121
• Add editor-color-palette-bootstrap4.json #2032
• Deprecate understrap_link_pages_args filter hook #1967
• Fix typos #2113
• Add grouped version updates for dependabot #2130
• Reduce code duplication by declaring copyDir() once #2129
• Fix and update workflows #2127

Other possibilities

• Comments - missing argument in comments.php function #2107
• ??

CC @IanDelMar

[IanDelMar]

#1967 - just throws a notice. But we need to change the version number from 1.3.0 to 1.2.3 if it is merged for the v1.2.3 release.
#2035 - important to merge asap
#2113 - does not introduce potentially breaking changes
#2118 - does not introduce potentially breaking changes

[bacoords]

I've updated my list above.
#2035 and #2118 are merged.
Merging #2113 opens up a new issue: #2123
We should be fine to merge #1967 I just want to do a little more testing on it

[IanDelMar]

#2123 is addressed in #2113

[bacoords]

@IanDelMar What are your thoughts about committing the rebuilt CSS/JS here - https://github.com/understrap/understrap/blob/cf16154caa254c934b2faa2cef4471f05bbe49c2/.github/workflows/build.yml#L68C14-L68C38

What's the reason for committing the changed files versus just testing that the build is working properly but not committing any changes?

[IanDelMar]

Well, we want to know what changes, if any, are caused by changes to either scss files or dependencies. When you commit the changes, you have a diff and can see those changes immediately. I find auto-committing things very handy. For example: Because of the auto-commit, I noticed that we need to bump the understrap postcss plugin in package-lock.json because there was this unexpected change:

Maybe there's another way to see these changes like a do diff and post the result in a comment, but most of the time you want to commit these changes anyway.

There is still a workflow issue. I need to check what to do about pushes that fail because of branch protection. When I tested the workflow in my repositories I didn't check for this scenario...

What are your thoughts?

[bacoords]

Yeah that makes sense. I'm not sure there's anything we can do about the branch protection issue

[bacoords]

I also noticed that the Linting action isn't running on PRs

[bacoords]

I take it back, we just haven't been changing any PHP files on the last few PRs, so I'm guessing it doesn't need to run.

[IanDelMar]

Yep, the linting workflow isn't supposed to run on PRs that do not change PHP files.

[IanDelMar]

@bacoords You have listed #2107 under "Other possibilities". I don't know what to do about this issue. I can't reproduce the error.

[bacoords]

Agreed - I don't think there's anything to do on that one for this release.