-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Default enable-api-fields
value for opt-in features once feature and API versioning are decoupled
#6948
Comments
Thanks @JeromeJu I think we should try and switch to These are 5 features currently in beta, which are enabled by default in the If we turned the I think the next steps could be:
|
Thank you Andrea for the investigations on the currently impacted beta features. I found csi and projected volume workspaces are documented to have become stable at tektoncd/community@d837715. I have been wondering if this would make sense as an example for other features that are currently at beta stability level now? Also I opened #6954 to keep sync of the TEP096 and our codebase. |
chatted offline with @afrittoli and we came to the following conclusions:
However, we are unsure of the best migration plan for getting enable-api-fields back to stable. Whenever we change enable-api-fields to stable, all beta features will go from enabled by default to disabled by default. Announcing it 9 months in advance gives cluster operators more time to adapt, but we don't know how many features will be in beta 9 months from now, so we don't know whether making this change in 9 months will result in more backwards incompatibility than making it at any other time. (We also don't want to stop new features from going to beta.) To work around this, @afrittoli suggested a new flag, something like legacy-enable-beta-features-by-default, that we'd phase out after 9 months. We'd default enable-api-fields to stable and introduce this flag at the same time, with a default value of "true", preserving existing behavior. The main concern we have about this is that it could be confusing. This chart would apply to the existing beta features (array results, array indexing, object params and results, and remote resolution):
This chart would apply to new beta features (e.g. probably matrix):
We'd love to know what others think about how to address this problem! |
I've chatted with @jerop and @dibyom and will summarize our conversation here: After writing up the table above, the three of us agree that another feature flag will add more complexity than necessary. We also all agree that the appropriate value for enable-api-fields is "stable". Dibyo has suggested that instead of changing validation for v1beta1, we simply document that the updated validation will apply to future beta APIs, and swap "enable-api-fields" back to stable. The reason for this suggestion is that the user impact from the existing bug (v1beta1 pipelineruns being unable to create taskruns when "enable-api-fields" is set to "stable") is likely smaller than the user impact of turning off beta features by default for v1beta1, and the bug can be avoided (i.e. the pipelinerun fails during validation rather than at runtime) by migrating to v1. |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
/remove-lifecycle stale |
Thanks for the reminder Vincent! During WG we have reached consensus that the default
|
Closing this as consensus has been reached and changes have been implemented. |
This issue tracks the decision to be made for the default
enable-api-fields
after decoupling the feature and api version. It has been discussed in the process of TEP0138 and is worth noted after the TEP being implemented. For context, we have changed the defaultenable-api-fields
to beta for the v1 storage swap , and with decoupling the feature and api version, we would be able to switch back tostable
enable-api-fields
for any version upgrades.Thanks to @lbernick and @afrittoli , there are couple of points to be discussed that are related:
enable-api-fields
tostable
enable-api-fields
in the long run?/kind feature
The text was updated successfully, but these errors were encountered: