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

ref(*): Change group versions from v1 to v1alpha1 #140

Merged
merged 1 commit into from
Mar 7, 2024
Merged

Conversation

calebschoepp
Copy link
Contributor

@calebschoepp calebschoepp commented Mar 6, 2024

Based off some reading seems like v1alpha1 is the version we want.

Closes #139

@calebschoepp
Copy link
Contributor Author

@endocrimes I'm confused why it is standard to put a number after the alpha or beta. Do you know what the historical context around that is?

@bacongobbler
Copy link
Contributor

bacongobbler commented Mar 6, 2024

I know it's there to signify what alpha release is being shipped to the user. The number signifies "the first alpha release". "alpha" and "beta" are the only two pre-release versions used in Kubernetes versioning until you go to "v1", so adding a number to the end allows them to continue to iterate. "alpha" signifies that the resource is highly unstable and changes to the manifest are highly likely. "beta" signifies that the manifest is stabilizing, but some changes may still occur between beta1 and v1.

From then on, it's marked as "v1" which is ready for production use. If you want to release a "v2", you go through the same process: "v2alphaX", "v2betaX", and finally "v2".

That is to say, "alpha2" should signify to the user that the resource is still highly unstable and major changes may still occur. The developers are not confident enough to call it a "beta" release, but they wanted to make some changes to the manifest since the first alpha release.

On the user side, Kubernetes Daemonsets went through multiple release cycles and continued to support each version while users were migrating. The API server supported both apps/v1beta1 and apps/v1beta2 up until Kubernetes 1.16 when it dropped all pre-release versions and told users to migrate to apps/v1.

Hope that helps!

Copy link
Contributor

@bacongobbler bacongobbler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I think we'll need to do the same changes over on the documentation repo as well as spin-plugin-k8s

@bacongobbler
Copy link
Contributor

I've gone ahead and made the changes in both locations:

spin-plugin-k8s's CI will need to re-run after this PR is merged as it's pointing to libraries that currently don't exist in main.

Copy link
Contributor

@endocrimes endocrimes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM but I would like to land #122 first (by nature of this being marginally easier to re-generate when rebased on top of those changes)

@calebschoepp
Copy link
Contributor Author

Thanks @bacongobbler that was a really helpful explanation!

Signed-off-by: Caleb Schoepp <caleb.schoepp@fermyon.com>
@calebschoepp calebschoepp merged commit f7068bc into main Mar 7, 2024
10 checks passed
@calebschoepp calebschoepp deleted the become-alpha branch March 7, 2024 18:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Change CRD version to be alpha
4 participants