Document release process for Crossplane extensions.

[jastang]

Adds a new Guide detailing the conventional release process with GitHub Actions for Crossplane extensions.

Fixes #785

[netlify]

✅ Deploy Preview for crossplane ready!

Name	Link
🔨 Latest commit	f117b12
🔍 Latest deploy log	https://app.netlify.com/projects/crossplane/deploys/6849e659186ba40008ad63c0
😎 Deploy Preview	https://deploy-preview-913--crossplane.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 60 (🔴 down 23 from production) Accessibility: 90 (🔴 down 2 from production) Best Practices: 83 (no change from production) SEO: 100 (no change from production) PWA: 70 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[jbw976]

This is a great start @jastang, thank you for stepping up to take on a long annoying gap in the community's knowledge base! 🙇‍♂️

I think we're still missing some high level and general information for folks that aren't ready to see the details of pipeline steps. Could you consider adding two IMO important focus areas to this guide?

• A high level general outline of what an extension release is, how the parts all fit together
• A practical set of steps that they follow to release their extension. This will probably be THE most useful and popular section of this guide. People would hopefully be able to come to this list and mostly follow it without thinking too much 😉

[jbw976]

Thanks for updating this guide @jastang! I think we have a lot of what we need here, maybe just a few small things to tie together the quick starts with the general guidance more strongly.

There may not be much this guide can do about the ecosystem fracturing we've caused, but let's see if there's anything we can do to improve on that, e.g. give folks concrete guidance to follow a single path instead of being confused about the options they have.

[jbw976]

something that still feels missing is the choices/actions around the release itself. do you feel like those are in scope here too? e.g. creating a release branch and/or tagging the release version.

or perhaps it could be as simple as adding here ...when you are ready to publish a release of your provider 😇

[jbw976]

beyond that though, I'm still personally struggling with the inconsistency we have introduced over time into the provider ecosystem. e.g. the ci.yaml for upjet-provider-template publishes on every CI run: https://github.com/crossplane/upjet-provider-template/blob/main/.github/workflows/ci.yml#L320-L322. It's sort of odd that we now have a separate workflow that is manually triggered, instead of just letting ci.yml publishing do the publishing itself.

This first came up in crossplane/org#88, we've sort of fractured the ecosystem into different paths that folks have to figure out themselves. is there much we can do in these docs to help people understand a single easy path to take? 🤔

[jastang]

fractured the ecosystem into different paths

completely agree here -- this became obvious as I was writing these docs. my understanding is that the reusable workflows are meant to be the desired "golden path" that requires fewer changes to Makefiles and other subtle configuration (cc @jeanduplessis @sergenyalcin to keep me honest here). I'm highlighting that path in these docs, but a follow-up would be to update the provider templates to include the reusable workflow and deprecate the publishing portion from ci.yml.

[jastang]

Thanks for the quick reviews @jbw976 🙇🏼 . I put the updates in a new commit here to hopefully make re-review easier.

[jbw976]

i like where we are ending up here @jastang - this is pretty much ready to go but a couple minor suggestions and a question about version inferring for you to consider - let me know when you feel good here and we can go ahead and merge! 🎉