search

liferay / clay

A web implementation of the Lexicon Experience Language
http://clayui.com
Other
206 stars 470 forks source link

Create release checklist #3475

Closed wincent closed 4 years ago

wincent commented 4 years ago

To reduce the likelihood of recurring, avoidable mistakes, such as introducing duplication in the yarn.lock when we update liferay-portal.

Brought up here, and then again here.

I'm not entirely sure how we can streamline this more than just mental overhead or a checklist, which is never great to rely on.

I get that it isn't great to rely on a checklist — bullet-proof automation would be even better — but given that we keep running into issues, I think we'll be better off having a checklist than not having one. Having said that, I have never prepared a Clay release — only releases of other projects, so feel free to ignore and close this if you want. Checklists have worked well for us in those other projects, to cover the gaps that automation can't (easily) fill.

bryceosterhaus commented 4 years ago

I have been following this checklist from my notes

  1. Navigate to ./modules/apps/frontend-taglib/frontend-taglib-clay
  2. Run ncu '/@clayui/' -u (npm-check-updates)
  3. Navigate to ./portal-impl and run ant format-source-all
  4. Run yarn from ./modules
  5. Run npx yarn-deduplicate yarn.lock

Am I missing something?

jbalsas commented 4 years ago

I think that should about do it... I'd add, maybe:

  1. Check yarn.log stats (git diff --stat yarn.lock) 6a. If diff numbers are off (more + then - or viceversa), review the contents to find an explanation
wincent commented 4 years ago

I'd always eyeball the yarn.lock even if the numbers look good.

paranoia

Also, forgot step 3a: "Wait 10 minutes".

just-sayin

bryceosterhaus commented 4 years ago

depending on the machine, sometimes 20min...

Also, whats with all the jsp/jspf changes that happen after step 3? I end up just only saving the package.json changes

wincent commented 4 years ago

Also, whats with all the jsp/jspf changes that happen after step 3?

Depends on what the changes are, I guess. Could be because CI only checks formatting on files that get changed in a PR, so if bad formatting ever gets committed to "master", it's possible that your local check (which checks everything) reports those as problems. 🤷‍♂️

I end up just only saving the package.json changes

Sounds like the right call to me! Maybe that could even go in the checklist as a note.