Develop Versioning / Release Strategy for Crossplane-Runtime

[hasheddan]

What problem are you facing?

As more repositories begin to take a dependency on crossplane-runtime, it is likely that different stacks will want to take a dependency on different versions of crossplane-runtime. Currently, this is done by pegging to a specific commit.

How could Crossplane help solve your problem?

A more robust semantic versioning strategy should be used to allow for clearly defined changes in the library. Useful references for library versioning include:

• controller-runtime
• kubebuilder
• controller-tools

[negz]

I think controller-runtime's strategy seems reasonable. My straw-man proposal to get this started would be to adopt a modified version of controller-runtime that:

• Uses Github labels instead of emojis to categorise PRs
• Disregards the Kubernetes workflow parts, since we don't use their build tooling

[negz]

Uses Github labels instead of emojis to categorise PRs

I just started working on updating the controller-runtime docs for our needs, and realised that folks without at least "triage" access (which lets you close PRs and issues) cannot add labels to pull requests. 👎

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.